From: Eric Dumazet <eric.dumazet@gmail.com>
To: paulmck@linux.vnet.ibm.com
Cc: dim@openvz.org, netdev@vger.kernel.org
Subject: Re: What protects rcu_dereference() in __sk_free()?
Date: Fri, 15 Jan 2010 06:59:25 +0100 [thread overview]
Message-ID: <4B50043D.9090205@gmail.com> (raw)
In-Reply-To: <20100114184107.GA17245@linux.vnet.ibm.com>
Le 14/01/2010 19:41, Paul E. McKenney a écrit :
> Hello, Dmitry,
>
> Could you please tell me what protects the rcu_dereference() in
> __sk_free()? I am adding lockdep-based checking to RCU, and
> "git blame" said I should ask you about this one.
>
> The current code, rcu_dereference(), assumes that this is protected only
> by RCU-bh. My problem might be any of the following:
>
> o Some other flavor of RCU protects this, e.g., RCU-sched, which
> would require rcu_dereference_sched() in place of my current
> rcu_dereference_bh() for RCU-bh.
>
> o This is called from updates as well as from readers, and
> some lock protects the updates.
>
> o This is called during initialization, when this pointer is
> inaccessible to readers.
>
> Please note that I can add a check to cover multiple possibilities.
> For a real example in include/linux/fdtable.h:
>
> file = rcu_dereference_check(fdt->fd[fd],
> rcu_read_lock_held() ||
> lockdep_is_held(&files->file_lock) ||
> atomic_read(&files->count) == 1);
>
> The first argument is the pointer, and the second argument says that
> this may be protected by either RCU (as opposed to RCU-bh, RCU-sched,
> or SRCU), the files->file_lock as recorded by lockdep, or by being in
> a single-threaded process as noted by the value of files->count.
> (Please see http://lwn.net/Articles/368683/ for a recent patch, another
> will go out soon.)
>
> So, could you please tell me what protects the rcu_dereference() in
> __sk_free() so that I can craft the appropriate form of rcu_dereference()?
>
Hi Paul
filter = rcu_dereference(sk->sk_filter);
is probably not really needed, current thread being the one doing socket destruction,
and has a writer role.
void sk_free(struct sock *sk)
{
if (atomic_dec_and_test(&sk->sk_wmem_alloc))
__sk_free(sk);
}
So the protection comes from the atomic_dec_and_test() that acts as a lock.
next prev parent reply other threads:[~2010-01-15 5:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-14 18:41 What protects rcu_dereference() in __sk_free()? Paul E. McKenney
2010-01-15 5:59 ` Eric Dumazet [this message]
2010-01-15 19:51 ` Paul E. McKenney
2010-01-16 8:55 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B50043D.9090205@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=dim@openvz.org \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.