Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 21 3月, 2006 12 次提交
  3. 14 3月, 2006 1 次提交
  5. 13 3月, 2006 2 次提交
  7. 12 3月, 2006 1 次提交
  9. 08 3月, 2006 1 次提交
  11. 28 2月, 2006 1 次提交
  13. 25 2月, 2006 2 次提交
  15. 19 2月, 2006 1 次提交
  17. 16 2月, 2006 2 次提交
  19. 14 2月, 2006 1 次提交
  21. 09 2月, 2006 1 次提交
  23. 08 2月, 2006 2 次提交
  25. 06 2月, 2006 1 次提交
  27. 05 2月, 2006 4 次提交
  29. 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
  31. 01 2月, 2006 1 次提交
    • E
      [IPV6] tcp_v6_send_synack: release the destination · 78b91042
      由 Eric W. Biederman 提交于 
      This patch fix dst reference counting in tcp_v6_send_synack

Analysis:
Currently tcp_v6_send_synack is never called with a dst entry
so dst always comes in as NULL.

ip6_dst_lookup calls ip6_route_output which calls dst_hold
before it returns the dst entry.   Neither xfrm_lookup
nor tcp_make_synack consume the dst entry so we still have
a dst_entry with a bumped refrence count at the end of
this function.

Therefore we need to call dst_release just before we return
just like tcp_v4_send_synack does.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      78b91042
  33. 25 1月, 2006 1 次提交
    • D
      [IPV6] MLDv2: fix change records when transitioning to/from inactive · 7add2a43
      由 David L Stevens 提交于 
      The following patch fixes these problems in MLDv2:

1) Add/remove "delete" records for sending change reports when
        addition of a filter results in that filter transitioning to/from
        inactive. [same as recent IPv4 IGMPv3 fix]
2) Remove 2 redundant "group_type" checks (can't be IPV6_ADDR_ANY
        within that loop, so checks are always true)
3) change an is_in() "return 0" to "return type == MLD2_MODE_IS_INCLUDE".
        It should always be "0" to get here, but it improves code locality 
        to not assume it, and if some race allowed otherwise, doing
        the check would return the correct result.
Signed-off-by: NDavid L Stevens <dlstevens@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7add2a43
  35. 17 1月, 2006 4 次提交