1. 10 1月, 2006 1 次提交
  2. 04 1月, 2006 2 次提交
  3. 23 11月, 2005 1 次提交
  4. 10 11月, 2005 4 次提交
    • T
      [NETLINK]: Generic netlink family · 482a8524
      Thomas Graf 提交于
      The generic netlink family builds on top of netlink and provides
      simplifies access for the less demanding netlink users. It solves
      the problem of protocol numbers running out by introducing a so
      called controller taking care of id management and name resolving.
      
      Generic netlink modules register themself after filling out their
      id card (struct genl_family), after successful registration the
      modules are able to register callbacks to command numbers by
      filling out a struct genl_ops and calling genl_register_op(). The
      registered callbacks are invoked with attributes parsed making
      life of simple modules a lot easier.
      
      Although generic netlink modules can request static identifiers,
      it is recommended to use GENL_ID_GENERATE and to let the controller
      assign a unique identifier to the module. Userspace applications
      will then ask the controller and lookup the idenfier by the module
      name.
      
      Due to the current multicast implementation of netlink, the number
      of generic netlink modules is restricted to 1024 to avoid wasting
      memory for the per socket multiacst subscription bitmask.
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      482a8524
    • T
      [NETLINK]: Generic netlink receive queue processor · 82ace47a
      Thomas Graf 提交于
      Introduces netlink_run_queue() to handle the receive queue of
      a netlink socket in a generic way. Processes as much as there
      was in the queue upon entry and invokes a callback function
      for each netlink message found. The callback function may
      refuse a message by returning a negative error code but setting
      the error pointer to 0 in which case netlink_run_queue() will
      return with a qlen != 0.
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      82ace47a
    • T
      [NETLINK]: Make netlink_callback->done() optional · a8f74b22
      Thomas Graf 提交于
      Most netlink families make no use of the done() callback, making
      it optional gets rid of all unnecessary dummy implementations.
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8f74b22
    • T
      [NETLINK]: Type-safe netlink messages/attributes interface · bfa83a9e
      Thomas Graf 提交于
      Introduces a new type-safe interface for netlink message and
      attributes handling. The interface is fully binary compatible
      with the old interface towards userspace. Besides type safety,
      this interface features attribute validation capabilities,
      simplified message contstruction, and documentation.
      
      The resulting netlink code should be smaller, less error prone
      and easier to understand.
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bfa83a9e
  5. 28 10月, 2005 1 次提交
  6. 26 10月, 2005 1 次提交
  7. 09 10月, 2005 1 次提交
  8. 07 9月, 2005 1 次提交
  9. 30 8月, 2005 9 次提交
  10. 19 7月, 2005 1 次提交
  11. 09 7月, 2005 1 次提交
  12. 27 6月, 2005 1 次提交
    • D
      [NETLINK]: Fix two socket hashing bugs. · d470e3b4
      David S. Miller 提交于
      1) netlink_release() should only decrement the hash entry
         count if the socket was actually hashed.
      
         This was causing hash->entries to underflow, which
         resulting in all kinds of troubles.
      
         On 64-bit systems, this would cause the following
         conditional to erroneously trigger:
      
      	err = -ENOMEM;
      	if (BITS_PER_LONG > 32 && unlikely(hash->entries >= UINT_MAX))
      		goto err;
      
      2) netlink_autobind() needs to propagate the error return from
         netlink_insert().  Otherwise, callers will not see the error
         as they should and thus try to operate on a socket with a zero pid,
         which is very bad.
      
         However, it should not propagate -EBUSY.  If two threads race
         to autobind the socket, that is fine.  This is consistent with the
         autobind behavior in other protocols.
      
         So bug #1 above, combined with this one, resulted in hangs
         on netlink_sendmsg() calls to the rtnetlink socket.  We'd try
         to do the user sendmsg() with the socket's pid set to zero,
         later we do a socket lookup using that pid (via the value we
         stashed away in NETLINK_CB(skb).pid), but that won't give us the
         user socket, it will give us the rtnetlink socket.  So when we
         try to wake up the receive queue, we dive back into rtnetlink_rcv()
         which tries to recursively take the rtnetlink semaphore.
      
      Thanks to Jakub Jelink for providing backtraces.  Also, thanks to
      Herbert Xu for supplying debugging patches to help track this down,
      and also finding a mistake in an earlier version of this fix.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d470e3b4
  13. 19 6月, 2005 1 次提交
  14. 20 5月, 2005 3 次提交
  15. 04 5月, 2005 1 次提交
    • H
      [NETLINK]: cb_lock does not needs ref count on sk · 96c36023
      Herbert Xu 提交于
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      96c36023
  16. 30 4月, 2005 1 次提交
  17. 29 4月, 2005 1 次提交
  18. 26 4月, 2005 2 次提交
    • A
      [NET]: kill gratitious includes of major.h · 5523662c
      Al Viro 提交于
      	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: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5523662c
    • A
      [PATCH] kill gratitious includes of major.h under net/* · b453257f
      Al Viro 提交于
      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: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b453257f
  19. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4