19 Jun, 2005

1 commit

  • Introduces a new macro NLMSG_NEW which extends NLMSG_PUT but takes
    a flags argument. NLMSG_PUT stays there for compatibility but now
    calls NLMSG_NEW with flags == 0. NLMSG_PUT_ANSWER is renamed to
    NLMSG_NEW_ANSWER which now also takes a flags argument.

    Also converts the users of NLMSG_PUT_ANSWER to use NLMSG_NEW_ANSWER
    and fixes the two direct users of __nlmsg_put to either provide
    the flags or use NLMSG_NEW(_ANSWER).

    Signed-off-by: Thomas Graf
    Signed-off-by: David S. Miller

    Thomas Graf
     

20 May, 2005

3 commits

  • In netlink_broadcast() we're sending shared skb's to netlink listeners
    when possible (saves some copying). This is OK, since we hold the only
    other reference to the skb.

    However, this implies that we must drop our reference on the skb, before
    allowing a receiving socket to disappear. Otherwise, the socket buffer
    accounting is disrupted.

    Signed-off-by: Tommy S. Christensen
    Acked-by: Herbert Xu
    Signed-off-by: David S. Miller

    Tommy S. Christensen
     
  • Cloned packets don't need the orphan call.

    Signed-off-by: Tommy S. Christensen
    Acked-by: Herbert Xu
    Signed-off-by: David S. Miller

    Tommy S. Christensen
     
  • This bug causes:

    assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122)

    What's happening is that:

    1) The skb is sent to socket 1.
    2) Someone does a recvmsg on socket 1 and drops the ref on the skb.
    Note that the rmalloc is not returned at this point since the
    skb is still referenced.
    3) The same skb is now sent to socket 2.

    This version of the fix resurrects the skb_orphan call that was moved
    out, last time we had 'shared-skb troubles'. It is practically a no-op
    in the common case, but still prevents the possible race with recvmsg.

    Signed-off-by: Tommy S. Christensen
    Acked-by: Herbert Xu
    Signed-off-by: David S. Miller

    Tommy S. Christensen
     

05 May, 2005

1 commit


04 May, 2005

1 commit

  • Here is a little optimisation for the cb_lock used by netlink_dump.
    While fixing that race earlier, I noticed that the reference count
    held by cb_lock is completely useless. The reason is that in order
    to obtain the protection of the reference count, you have to take
    the cb_lock. But the only way to take the cb_lock is through
    dereferencing the socket.

    That is, you must already possess a reference count on the socket
    before you can take advantage of the reference count held by cb_lock.
    As a corollary, we can remve the reference count held by the cb_lock.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

30 Apr, 2005

1 commit

  • scumbags!

    net/netlink/af_netlink.c: In function `netlink_sendmsg':
    net/netlink/af_netlink.c:908: warning: implicit declaration of function `audit_get_loginuid'

    Signed-off-by: Andrew Morton
    Signed-off-by: David Woodhouse

    Andrew Morton
     

29 Apr, 2005

1 commit

  • Most audit control messages are sent over netlink.In order to properly
    log the identity of the sender of audit control messages, we would like
    to add the loginuid to the netlink_creds structure, as per the attached
    patch.

    Signed-off-by: Serge Hallyn
    Signed-off-by: David Woodhouse

    Serge Hallyn
     

26 Apr, 2005

1 commit

  • A lot of places in there are including major.h for no reason whatsoever.
    Removed. And yes, it still builds.

    The history of that stuff is often amusing. E.g. for net/core/sock.c
    the story looks so, as far as I've been able to reconstruct it: we used
    to need major.h in net/socket.c circa 1.1.early. In 1.1.13 that need
    had disappeared, along with register_chrdev(SOCKET_MAJOR, "socket",
    &net_fops) in sock_init(). Include had not. When 1.2 -> 1.3 reorg of
    net/* had moved a lot of stuff from net/socket.c to net/core/sock.c,
    this crap had followed...

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

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