All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: yoshfuji@linux-ipv6.org, netdev@vger.kernel.org, mingo@elte.hu,
	akpm@linux-foundation.org, peterz@infradead.org
Subject: Re: What protects rcu_dereference() in __in6_dev_get()?
Date: Fri, 15 Jan 2010 07:15:59 -0800	[thread overview]
Message-ID: <20100115151559.GD6770@linux.vnet.ibm.com> (raw)
In-Reply-To: <4B500217.6070908@gmail.com>

On Fri, Jan 15, 2010 at 06:50:15AM +0100, Eric Dumazet wrote:
> Le 14/01/2010 19:32, Paul E. McKenney a écrit :
> > Hello, Yoshi,
> > 
> > Could you please tell me what protects the rcu_dereference() in
> > __in6_dev_get()?  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.  My problem might be any of the following:
> > 
> > o	Some other flavor of RCU protects this, e.g., RCU-bh, which
> > 	would require rcu_dereference_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 __in6_dev_get() so that I can craft the appropriate form of
> > rcu_dereference()?
> > 
> > 							Thanx, Paul
> 
> Hi Paul
> 
> __in6_dev_get() is called either with rcu_read_lock()/rcu_read_unlock() protection,
> or with the RTNL mutex held.

Very good!  So I make a lockdep_rtnl_is_held() in net/core/rtnetlink.c:

	#ifdef CONFIG_PROVE_LOCKING
	int lockdep_rtnl_is_held(void)
	{
		return lockdep_is_held(&rtnl_mutex);
	}
	EXPORT_SYMBOL(lockdep_rtnl_is_held);
	#endif /* #ifdef CONFIG_PROVE_LOCKING */

Then I make __in6_dev_get() look as follows:

	static inline struct inet6_dev *
	__in6_dev_get(struct net_device *dev)
	{
		return rcu_dereference_check(dev->ip6_ptr,
					     rcu_read_lock_held() ||
					     lockdep_rtnl_is_held());
	}

Seem reasonable?

> Well, thats the theory, we could have some bugs of course :)

I know that feeling!  ;-)

						Thanx, Paul

  reply	other threads:[~2010-01-15 15:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-14 18:32 What protects rcu_dereference() in __in6_dev_get()? Paul E. McKenney
2010-01-15  5:50 ` Eric Dumazet
2010-01-15 15:15   ` Paul E. McKenney [this message]
2010-01-15 15:29     ` Eric Dumazet
2010-01-15 15:31       ` Peter Zijlstra
2010-01-15 15:53       ` Paul E. McKenney

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=20100115151559.GD6770@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=eric.dumazet@gmail.com \
    --cc=mingo@elte.hu \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=yoshfuji@linux-ipv6.org \
    /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.