[lkml]   [2010]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/2] rcu: add rcu_access_pointer and rcu_dereference_protect
    Eric Dumazet <> wrote:

    > > You've missed the point.
    > You already claimed I dont understand RCU. I find this claim funny.
    > > For rcu_access_pointer(), _nothing_ protects the data, not only that, we
    > > don't care: we're only checking the pointer.
    > How can you state this ?
    > Thats pretty simple, "always true" is a fine condition.
    > What's the problem with this ?

    If the condition for rcu_access_pointer() is always "always true", then it's
    redundant, right? rcu_access_pointer() is for checking the pointer only, not
    checking the payload that pointer might point to. So, what condition are you
    supposed to be checking?
    Eric Dumazet <> wrote:

    > > but if 'c' is supposed to be the locks that protect the data, is this a
    > > valid check?
    > 'c' is not a lock. Its a condition.

    Sorry, I meant the state of the relevant locking context.

    To take your example:

    > filter = rcu_dereference_check(sk->sk_filter,
    > atomic_read(&sk->sk_wmem_alloc) == 0);

    what is the value of sk->sk_wmem_alloc to the lock context of sk->sk_filter?
    Why would lockdep be interested in sk_wmem_alloc?

    Surely, the assertion that the value of sk->sk_filter is related to
    sk_wmem_alloc being 0 is independent of the need to dereference sk_filter for
    RCU purposes. So why are these being combined?

    Why not:

    ASSERT(atomic_read(&sk->sk_wmem_alloc) == 0);
    filter = rcu_dereference(sk->sk_filter);

    This is much clearer, and you're not combining an unrelated assertion with the
    RCU dereference.


     \ /
      Last update: 2010-04-07 18:23    [W:0.020 / U:11.760 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site