1. 30 12月, 2008 1 次提交
  2. 21 11月, 2008 1 次提交
  3. 12 11月, 2008 2 次提交
  4. 04 11月, 2008 1 次提交
    • A
      net: '&' redux · 6d9f239a
      Alexey Dobriyan 提交于
      I want to compile out proc_* and sysctl_* handlers totally and
      stub them to NULL depending on config options, however usage of &
      will prevent this, since taking adress of NULL pointer will break
      compilation.
      
      So, drop & in front of every ->proc_handler and every ->strategy
      handler, it was never needed in fact.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d9f239a
  5. 29 10月, 2008 1 次提交
  6. 23 9月, 2008 1 次提交
  7. 03 8月, 2008 2 次提交
  8. 17 7月, 2008 1 次提交
    • N
      core: add stat to track unresolved discards in neighbor cache · 9a6d276e
      Neil Horman 提交于
      in __neigh_event_send, if we have a neighbour entry which is in
      NUD_INCOMPLETE state, we enqueue any outbound frames to that neighbour
      to the neighbours arp_queue, which is default capped to a length of 3
      skbs.  If that queue exceeds its set length, it will drop an skb on
      the queue to enqueue the newly arrived skb.  This results in a drop
      for which we have no statistics incremented.  This patch adds an
      unresolved_discards stat to /proc/net/stat/ndisc_cache to track these
      lost frames.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a6d276e
  9. 04 6月, 2008 2 次提交
    • T
      netlink: Improve returned error codes · bc3ed28c
      Thomas Graf 提交于
      Make nlmsg_trim(), nlmsg_cancel(), genlmsg_cancel(), and
      nla_nest_cancel() void functions.
      
      Return -EMSGSIZE instead of -1 if the provided message buffer is not
      big enough.
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc3ed28c
    • S
      net: neighbour table ABI problem · b9f5f52c
      Stephen Hemminger 提交于
      The neighbor table time of last use information is returned in the
      incorrect unit. Kernel to user space ABI's need to use USER_HZ (or
      milliseconds), otherwise the application has to try and discover the
      real system HZ value which is problematic.  Linux has standardized on
      keeping USER_HZ consistent (100hz) even when kernel is running
      internally at some other value.
      
      This change is small, but it breaks the ABI for older version of
      iproute2 utilities.  But these utilities are already broken since they
      are looking at the psched_hz values which are completely different. So
      let's just go ahead and fix both kernel and user space. Older
      utilities will just print wrong values.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9f5f52c
  10. 02 5月, 2008 1 次提交
  11. 28 3月, 2008 2 次提交
  12. 26 3月, 2008 5 次提交
  13. 25 3月, 2008 1 次提交
    • P
      [NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns (v3). · fa86d322
      Pavel Emelyanov 提交于
      Proxy neighbors do not have any reference counting, so any caller
      of pneigh_lookup (unless it's a netlink triggered add/del routine)
      should _not_ perform any actions on the found proxy entry. 
      
      There's one exception from this rule - the ipv6's ndisc_recv_ns() 
      uses found entry to check the flags for NTF_ROUTER.
      
      This creates a race between the ndisc and pneigh_delete - after 
      the pneigh is returned to the caller, the nd_tbl.lock is dropped 
      and the deleting procedure may proceed.
      
      One of the fixes would be to add a reference counting, but this
      problem exists for ndisc only. Besides such a patch would be too 
      big for -rc4.
      
      So I propose to introduce a __pneigh_lookup() which is supposed
      to be called with the lock held and use it in ndisc code to check
      the flags on alive pneigh entry.
      
      
      Changes from v2:
      As David noticed, Exported the __pneigh_lookup() to ipv6 module. 
      The checkpatch generates a warning on it, since the EXPORT_SYMBOL 
      does not follow the symbol itself, but in this file all the 
      exports come at the end, so I decided no to break this harmony.
      
      Changes from v1:
      Fixed comments from YOSHIFUJI - indentation of prototype in header
      and the pndisc_check_router() name - and a compilation fix, pointed
      by Daniel - the is_routed was (falsely) considered as uninitialized
      by gcc.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa86d322
  14. 04 3月, 2008 1 次提交
  15. 29 2月, 2008 3 次提交
  16. 24 2月, 2008 1 次提交
  17. 20 2月, 2008 1 次提交
  18. 18 2月, 2008 1 次提交
  19. 13 2月, 2008 1 次提交
    • D
      [NDISC]: Fix race in generic address resolution · 69cc64d8
      David S. Miller 提交于
      Frank Blaschka provided the bug report and the initial suggested fix
      for this bug.  He also validated this version of this fix.
      
      The problem is that the access to neigh->arp_queue is inconsistent, we
      grab references when dropping the lock lock to call
      neigh->ops->solicit() but this does not prevent other threads of
      control from trying to send out that packet at the same time causing
      corruptions because both code paths believe they have exclusive access
      to the skb.
      
      The best option seems to be to hold the write lock on neigh->lock
      during the ->solicit() call.  I looked at all of the ndisc_ops
      implementations and this seems workable.  The only case that needs
      special care is the IPV4 ARP implementation of arp_solicit().  It
      wants to take neigh->lock as a reader to protect the header entry in
      neigh->ha during the emission of the soliciation.  We can simply
      remove the read lock calls to take care of that since holding the lock
      as a writer at the caller providers a superset of the protection
      afforded by the existing read locking.
      
      The rest of the ->solicit() implementations don't care whether the
      neigh is locked or not.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69cc64d8
  20. 29 1月, 2008 11 次提交