1. 28 12月, 2005 1 次提交
  2. 24 12月, 2005 2 次提交
  3. 22 12月, 2005 1 次提交
    • K
      [IPV6]: Fix address deletion · 1d142804
      Kristian Slavov 提交于
      If you add more than one IPv6 address belonging to the same prefix and 
      delete the address that was last added, routing table entry for that 
      prefix is also deleted.
      Tested on 2.6.14.4
      
      To reproduce:
      ip addr add 3ffe::1/64 dev eth0
      ip addr add 3ffe::2/64 dev eth0
      /* wait DAD */
      sleep 1
      ip addr del 3ffe::2/64 dev eth0
      ip -6 route
      
      (route to 3ffe::/64 should be gone)
      
      In ipv6_del_addr(), if ifa == ifp, we set ifa->if_next to NULL, and later 
      assign ifap = &ifa->if_next, effectively terminating the for-loop.
      This prevents us from checking if there are other addresses using the same 
      prefix that are valid, and thus resulting in deletion of the prefix.
      This applies only if the first entry in idev->addr_list is the address to 
      be deleted.
      Signed-off-by: NKristian Slavov <kristian.slavov@nomadiclab.com>
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d142804
  4. 21 12月, 2005 3 次提交
  5. 20 12月, 2005 1 次提交
    • Y
      [IPV6]: Fix route lifetime. · 3dd4bc68
      YOSHIFUJI Hideaki 提交于
      The route expiration time is stored in rt6i_expires in jiffies.
      The argument of rt6_route_add() for adding a route is not the
      expiration time in jiffies nor in clock_t, but the lifetime
      (or time left before expiration) in clock_t.
      
      Because of the confusion, we sometimes saw several strange errors
      (FAILs) in TAHI IPv6 Ready Logo Phase-2 Self Test.
      The symptoms were analyzed by Mitsuru Chinen <CHINEN@jp.ibm.com>.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3dd4bc68
  6. 14 12月, 2005 1 次提交
  7. 29 11月, 2005 1 次提交
  8. 21 11月, 2005 1 次提交
  9. 15 11月, 2005 1 次提交
  10. 10 11月, 2005 1 次提交
  11. 09 11月, 2005 3 次提交
  12. 03 11月, 2005 1 次提交
  13. 30 10月, 2005 1 次提交
  14. 04 10月, 2005 1 次提交
    • H
      [IPV4]: Replace __in_dev_get with __in_dev_get_rcu/rtnl · e5ed6399
      Herbert Xu 提交于
      The following patch renames __in_dev_get() to __in_dev_get_rtnl() and
      introduces __in_dev_get_rcu() to cover the second case.
      
      1) RCU with refcnt should use in_dev_get().
      2) RCU without refcnt should use __in_dev_get_rcu().
      3) All others must hold RTNL and use __in_dev_get_rtnl().
      
      There is one exception in net/ipv4/route.c which is in fact a pre-existing
      race condition.  I've marked it as such so that we remember to fix it.
      
      This patch is based on suggestions and prior work by Suzanne Wood and
      Paul McKenney.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5ed6399
  15. 27 9月, 2005 1 次提交
  16. 10 9月, 2005 1 次提交
  17. 02 9月, 2005 1 次提交
    • J
      [CRYPTO]: crypto_free_tfm() callers no longer need to check for NULL · 573dbd95
      Jesper Juhl 提交于
      Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
      there's no longer any need for callers of that function to check for NULL.
      This patch removes the redundant NULL checks and also a few similar checks
      for NULL before calls to kfree() that I ran into while doing the
      crypto_free_tfm bits.
      
      I've succesfuly compile tested this patch, and a kernel with the patch 
      applied boots and runs just fine.
      
      When I posted the patch to LKML (and other lists/people on Cc) it drew the
      following comments :
      
       J. Bruce Fields commented
        "I've no problem with the auth_gss or nfsv4 bits.--b."
      
       Sridhar Samudrala said
        "sctp change looks fine."
      
       Herbert Xu signed off on the patch.
      
      So, I guess this is ready to be dropped into -mm and eventually mainline.
      Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      573dbd95
  18. 30 8月, 2005 4 次提交
  19. 29 6月, 2005 3 次提交
  20. 24 6月, 2005 1 次提交
  21. 22 6月, 2005 1 次提交
  22. 19 6月, 2005 3 次提交
  23. 14 6月, 2005 1 次提交
    • R
      [IPv6] Don't generate temporary for TUN devices · 77bd9196
      Rémi Denis-Courmont 提交于
      Userland layer-2 tunneling devices allocated through the TUNTAP driver 
      (drivers/net/tun.c) have a type of ARPHRD_NONE, and have no link-layer 
      address. The kernel complains at regular interval when IPv6 Privacy 
      extension are enabled because it can't find an hardware address :
      
      Dec 29 11:02:04 auguste kernel: __ipv6_regen_rndid(idev=cb3e0c00): 
      cannot get EUI64 identifier; use random bytes.
      
      IPv6 Privacy extensions should probably be disabled on that sort of 
      device. They won't work anyway. If userland wants a more usual 
      Ethernet-ish interface with usual IPv6 autoconfiguration, it will use a 
      TAP device with an emulated link-layer  and a random hardware address 
      rather than a TUN device.
      
      As far as I could fine, TUN virtual device from TUNTAP is the very only 
      sort of device using ARPHRD_NONE as kernel device type.
      Signed-off-by: NRmi Denis-Courmont <rdenis@simphalempin.com>
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      77bd9196
  24. 04 5月, 2005 1 次提交
  25. 20 4月, 2005 1 次提交
  26. 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