An error occurred fetching the project authors.
  1. 19 May, 2008 1 commit
  2. 13 May, 2008 1 commit
  3. 12 Apr, 2008 2 commits
  4. 03 Apr, 2008 4 commits
  5. 28 Mar, 2008 1 commit
  6. 26 Mar, 2008 1 commit
  7. 25 Mar, 2008 2 commits
  8. 24 Mar, 2008 2 commits
    • Pavel Emelyanov's avatar
      [NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns (v3). · fa86d322
      Pavel Emelyanov authored
      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: default avatarPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa86d322
    • Rami Rosen's avatar
      [IPV6]: Remove unused code in ndisc_send_redirect(). · 061964fb
      Rami Rosen authored
      This patches removes unused code in ndisc_send_redirect() method in
      net/ipv6/ndisc.c.
      Signed-off-by: default avatarRami Rosen <ramirose@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      061964fb
  9. 23 Mar, 2008 1 commit
  10. 07 Mar, 2008 2 commits
  11. 06 Mar, 2008 1 commit
  12. 05 Mar, 2008 1 commit
  13. 04 Mar, 2008 3 commits
  14. 29 Feb, 2008 1 commit
  15. 28 Jan, 2008 6 commits
  16. 25 Jan, 2008 1 commit
    • Rolf Manderscheid's avatar
      IPoIB: improve IPv4/IPv6 to IB mcast mapping functions · a9e527e3
      Rolf Manderscheid authored
      An IPoIB subnet on an IB fabric that spans multiple IB subnets can't
      use link-local scope in multicast GIDs.  The existing routines that
      map IP/IPv6 multicast addresses into IB link-level addresses hard-code
      the scope to link-local, and they also leave the partition key field
      uninitialised.  This patch adds a parameter (the link-level broadcast
      address) to the mapping routines, allowing them to initialise both the
      scope and the P_Key appropriately, and fixes up the call sites.
      
      The next step will be to add a way to configure the scope for an IPoIB
      interface.
      Signed-off-by: default avatarRolf Manderscheid <rvm@obsidianresearch.com>
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      a9e527e3
  17. 20 Dec, 2007 1 commit
  18. 13 Nov, 2007 1 commit
  19. 30 Oct, 2007 1 commit
  20. 18 Oct, 2007 1 commit
  21. 11 Oct, 2007 1 commit
    • Pierre Ynard's avatar
      [IPv6]: Export userland ND options through netlink (RDNSS support) · 31910575
      Pierre Ynard authored
      As discussed before, this patch provides userland with a way to access
      relevant options in Router Advertisements, after they are processed
      and validated by the kernel. Extra options are processed in a generic
      way; this patch only exports RDNSS options described in RFC5006, but
      support to control which options are exported could be easily added.
      
      A new rtnetlink message type is defined, to transport Neighbor
      Discovery options, along with optional context information. At the
      moment only the address of the router sending an RDNSS option is
      included, but additional attributes may be later defined, if needed by
      new use cases.
      Signed-off-by: default avatarPierre Ynard <linkfanel@yahoo.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31910575
  22. 10 Oct, 2007 4 commits
  23. 08 Oct, 2007 1 commit
    • Brian Haley's avatar
      [IPv6]: Fix ICMPv6 redirect handling with target multicast address · bf0b48df
      Brian Haley authored
      When the ICMPv6 Target address is multicast, Linux processes the 
      redirect instead of dropping it.  The problem is in this code in 
      ndisc_redirect_rcv():
      
               if (ipv6_addr_equal(dest, target)) {
                       on_link = 1;
               } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
                       ND_PRINTK2(KERN_WARNING
                                  "ICMPv6 Redirect: target address is not 
      link-local.\n");
                       return;
               }
      
      This second check will succeed if the Target address is, for example, 
      FF02::1 because it has link-local scope.  Instead, it should be checking 
      if it's a unicast link-local address, as stated in RFC 2461/4861 Section 
      8.1:
      
             - The ICMP Target Address is either a link-local address (when
               redirected to a router) or the same as the ICMP Destination
               Address (when redirected to the on-link destination).
      
      I know this doesn't explicitly say unicast link-local address, but it's 
      implied.
      
      This bug is preventing Linux kernels from achieving IPv6 Logo Phase II 
      certification because of a recent error that was found in the TAHI test 
      suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the 
      multicast address in the Destination field instead of Target field, so 
      we were passing the test.  This won't be the case anymore.
      
      The patch below fixes this problem, and also fixes ndisc_send_redirect() 
      to not send an invalid redirect with a multicast address in the Target 
      field.  I re-ran the TAHI Neighbor Discovery section to make sure Linux 
      passes all 245 tests now.
      Signed-off-by: default avatarBrian Haley <brian.haley@hp.com>
      Acked-by: default avatarDavid L Stevens <dlstevens@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf0b48df