1. 21 3月, 2006 18 次提交
  2. 14 3月, 2006 1 次提交
  3. 13 3月, 2006 2 次提交
  4. 12 3月, 2006 1 次提交
  5. 08 3月, 2006 1 次提交
  6. 28 2月, 2006 1 次提交
  7. 25 2月, 2006 2 次提交
  8. 19 2月, 2006 1 次提交
  9. 16 2月, 2006 2 次提交
  10. 14 2月, 2006 1 次提交
  11. 09 2月, 2006 1 次提交
  12. 08 2月, 2006 2 次提交
  13. 06 2月, 2006 1 次提交
  14. 05 2月, 2006 4 次提交
  15. 03 2月, 2006 2 次提交
    • H
      [IPV6]: Fix illegal dst locking in softirq context. · 6f4b6ec1
      Herbert Xu 提交于
      On Tue, Jan 31, 2006 at 10:24:32PM +0100, Ingo Molnar wrote:
      >
      >  [<c04de9e8>] _write_lock+0x8/0x10
      >  [<c0499015>] inet6_destroy_sock+0x25/0x100
      >  [<c04b8672>] tcp_v6_destroy_sock+0x12/0x20
      >  [<c046bbda>] inet_csk_destroy_sock+0x4a/0x150
      >  [<c047625c>] tcp_rcv_state_process+0xd4c/0xdd0
      >  [<c047d8e9>] tcp_v4_do_rcv+0xa9/0x340
      >  [<c047eabb>] tcp_v4_rcv+0x8eb/0x9d0
      
      OK this is definitely broken.  We should never touch the dst lock in
      softirq context.  Since inet6_destroy_sock may be called from that
      context due to the asynchronous nature of sockets, we can't take the
      lock there.
      
      In fact this sk_dst_reset is totally redundant since all IPv6 sockets
      use inet_sock_destruct as their socket destructor which always cleans
      up the dst anyway.  So the solution is to simply remove the call.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f4b6ec1
    • H
      [IPV6]: Don't hold extra ref count in ipv6_ifa_notify · 4641e7a3
      Herbert Xu 提交于
      Currently the logic in ipv6_ifa_notify is to hold an extra reference
      count for addrconf dst's that get added to the routing table.  Thus,
      when addrconf dst entries are taken out of the routing table, we need
      to drop that dst.  However, addrconf dst entries may be removed from
      the routing table by means other than __ipv6_ifa_notify.
      
      So we're faced with the choice of either fixing up all places where
      addrconf dst entries are removed, or dropping the extra reference count
      altogether.
      
      I chose the latter because the ifp itself always holds a dst reference
      count of 1 while it's alive.  This is dropped just before we kfree the
      ifp object.  Therefore we know that in __ipv6_ifa_notify we will always
      hold that count.
      
      This bug was found by Eric W. Biederman.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4641e7a3