11 May, 2015

1 commit


03 Mar, 2015

1 commit

  • After TIPC doesn't depend on iocb argument in its internal
    implementations of sendmsg() and recvmsg() hooks defined in proto
    structure, no any user is using iocb argument in them at all now.
    Then we can drop the redundant iocb argument completely from kinds of
    implementations of both sendmsg() and recvmsg() in the entire
    networking stack.

    Cc: Christoph Hellwig
    Suggested-by: Al Viro
    Signed-off-by: Ying Xue
    Signed-off-by: David S. Miller

    Ying Xue
     

23 Nov, 2011

1 commit


01 Oct, 2009

1 commit

  • This provides safety against negative optlen at the type
    level instead of depending upon (sometimes non-trivial)
    checks against this sprinkled all over the the place, in
    each and every implementation.

    Based upon work done by Arjan van de Ven and feedback
    from Linus Torvalds.

    Signed-off-by: David S. Miller

    David S. Miller
     

04 Dec, 2008

1 commit

  • We lack compat ioctl support through most of the ATM code. This patch
    deals with most of it, and I can now at least use BR2684 and PPPoATM
    with 32-bit userspace.

    I haven't added a .compat_ioctl method to struct atm_ioctl, because
    AFAICT none of the current users need any conversion -- so we can just
    call the ->ioctl() method in every case. I looked at br2684, clip, lec,
    mpc, pppoatm and atmtcp.

    In svc_compat_ioctl() the only mangling which is needed is to change
    COMPAT_ATM_ADDPARTY to ATM_ADDPARTY. Although it's defined as
    _IOW('a', ATMIOC_SPECIAL+4,struct atm_iobuf)
    it doesn't actually _take_ a struct atm_iobuf as an argument -- it takes
    a struct sockaddr_atmsvc, which _is_ the same between 32-bit and 64-bit
    code, so doesn't need conversion.

    Almost all of vcc_ioctl() would have been identical, so I converted that
    into a core do_vcc_ioctl() function with an 'int compat' argument.

    I've done the same with atm_dev_ioctl(), where there _are_ a few
    differences, but still it's relatively contained and there would
    otherwise have been a lot of duplication.

    I haven't done any of the actual device-specific ioctls, although I've
    added a compat_ioctl method to struct atmdev_ops.

    Signed-off-by: David Woodhouse
    Signed-off-by: David S. Miller

    David Woodhouse
     

11 Oct, 2007

1 commit

  • This patch passes in the namespace a new socket should be created in
    and has the socket code do the appropriate reference counting. By
    virtue of this all socket create methods are touched. In addition
    the socket create methods are modified so that they will fail if
    you attempt to create a socket in a non-default network namespace.

    Failing if we attempt to create a socket outside of the default
    network namespace ensures that as we incrementally make the network stack
    network namespace aware we will not export functionality that someone
    has not audited and made certain is network namespace safe.
    Allowing us to partially enable network namespaces before all of the
    exotic protocols are supported.

    Any protocol layers I have missed will fail to compile because I now
    pass an extra parameter into the socket creation code.

    [ Integrated AF_IUCV build fixes from Andrew Morton... -DaveM ]

    Signed-off-by: Eric W. Biederman
    Signed-off-by: David S. Miller

    Eric W. Biederman
     

11 Feb, 2007

1 commit


30 Jun, 2006

1 commit


30 Nov, 2005

1 commit

  • atm_dev_deregister() removes device from atm_dev list immediately to
    prevent operations on a phantom device. Decision to free device based
    only on ->refcnt now. Remove shutdown_atm_dev() use atm_dev_deregister()
    instead. atm_dev_deregister() also asynchronously releases all vccs
    related to device.

    Signed-off-by: Stanislaw Gruszka
    Signed-off-by: Chas Williams
    Signed-off-by: David S. Miller

    Stanislaw Gruszka
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds