Re: [PATCH][MCAST]IPv6: doubt about ipv6_sk_mc_lock usage.

From: David Stevens (dlstevens_at_us.ibm.com)
Date: 10/31/05

  • Next message: Ingo Molnar: "[patch] preempt-trace.patch"
    To: Yan Zheng <yanzheng@21cn.com>
    Date:	Mon, 31 Oct 2005 13:37:46 -0800
    
    

    > I have one more question.
    > Why ip6_mc_source() uses read_lock_bh(&ipv6_sk_mc_lock) and
    ip6_mc_msfilter()
    > doesn't use ipv6_sk_mc_lock at all.
    > when ipv6_mc_list's sflist are accessed by inet6_mc_check(), Can it be
    > modified by ip6_mc_source() or ip6_mc_msfilter() ?
    > (For example ipv6_mc_list's sflist is freed up by sock_kfree_s(), when
    > inet6_mc_check() uses it)

    Yan,

    There certainly may be a bug, but removing the lock isn't the fix. :-)

    inet6_mc_check() does not have the socket locked, but is acquiring a
    read lock on ipv6_sk_mc_lock.

    I've looked some more into this, and I believe ip6_mc_msfilter() needs
    at least a read lock on ipv6_sk_mc_lock to protect it from races with
    changes to the list, just as ip6_mc_source() has.

    I convinced myself at the time that the sflist does not require an
    additional lock, but I don't see that now. It seems to me now that
    there should be a lock on each individual socklist entry and changes
    to the socket source filter should be protected by that. A simpler,
    but less performant, fix would be to make both ipv6_mc_source() and
    ip6_mc_msfilter() acquire ipv6_sk_mc_lock for writing, to prevent
    races with inet6_mc_check's search of the sflist.

    It'd be much better if only that socklist entry is locked, of course.

    I'll look some more.

                            +-DLS

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Ingo Molnar: "[patch] preempt-trace.patch"

    Relevant Pages

    • Re: [PATCH] Instrumenting high latency
      ... > so if need_reschedstays false then this will hold the lock for a long ... On all CPUs. ... If that causes the kernel to livelock then we need to fix that ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [patch-stable 3/3] pi-futex: Fix exit races and locking problems
      ... My fix works. ... and making all the work in context of process taking lock. ... We are the first waiter - try to look up the real owner and attach ... while (!ret) { ...
      (Linux-Kernel)
    • [patch 05/26] pi-futex: Fix exit races and locking problems
      ... My fix works. ... and making all the work in context of process taking lock. ... We are the first waiter - try to look up the real owner and attach ... while (!ret) { ...
      (Linux-Kernel)
    • Re: [GIT PULL] block/splice bits for 2.6.29
      ... Fix small typo in bio.h's documentation ... This patch is wrong, in fact Vergard has noted this in patch log. ... prefer just unifying the lock ordering. ...
      (Linux-Kernel)
    • Re: Guidance please - impending GPU and DVD failure?
      ... Since the 360 was mounted upright, ... left the console downloading something overnight when it was still ... lock up is a total freeze, with lines of dots appearing all over the ... any idea if MS will suggest that they would fix ...
      (uk.games.video.xbox)