All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Matt Helsley <matthltc@us.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Li Zefan <lizf@cn.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"containers@lists.osdl.org" <containers@lists.osdl.org>,
	Paul Menage <menage@google.com>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 3/5] sched: Fix an RCU warning in print_task()
Date: Thu, 22 Apr 2010 15:05:04 -0700	[thread overview]
Message-ID: <20100422220504.GP2524@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100422211212.GA32490@count0.beaverton.ibm.com>

On Thu, Apr 22, 2010 at 02:12:12PM -0700, Matt Helsley wrote:
> On Thu, Apr 22, 2010 at 12:20:04PM +0200, Peter Zijlstra wrote:
> 
> <snip>
> 
> > You can also pin a cgroup by holding whatever locks are held in the
> > ->attach method. But the RCU annotation doesn't know (nor reasonably can
> > know about that).
> 
> For my future reference, what's the right way to "fix" these
> situations with the RCU annotations? (I think your response re: Li's
> freezer patch was correct and illustrates the problem I'm referring to.)

There are several variants of rcu_dereference() for this purpose:

o	rcu_dereference() for code that is always called within an
	RCU read-side critical section -- rcu_read_lock().

o	rcu_dereference_bh() for code that is always called within
	an RCU-bh read-side critical section -- rcu_read_lock_bh().

o	rcu_dereference_sched() for code that is always called within
	an RCU-sched read-side critical section -- either
	rcu_read_lock_sched() or any other primitive that disables
	preemption.

o	srcu_dereference() for code that is always called within an
	SRCU read-side critical section -- srcu_read_lock().

o	rcu_dereference_check() for code that might be called either
	in a read-side critical section or on the update side.	This
	interface takes a second argument, which is normally a logical
	conjunction of rcu_read_lock_held(), rcu_read_lock_sched_held(),
	rcu_read_lock_bh_held(), and srcu_read_lock_held for the read
	side, and lockdep_is_held() for the update side.

o	rcu_dereference_raw(p) is rcu_dereference_check(p, 1).  Expect
	to be asked hard questions if you include this in your patch.
	One legitimate use is for initialization and cleanup code
	sequences where the current CPU is the only one with access
	to the RCU-protected data structure in question.

o	rcu_dereference_protected() for code that is only called from
	the update side.  This interface takes a second argument,
	which would normally only have a logical conjunction of
	lockdep_is_held() invocations.  Don't even think about putting
	rcu_read_lock_held() and friends here!!!

o	rcu_access_pointer() for code that only tests the value of
	the RCU-protected pointer, for example, against NULL.

There you have it!

							Thanx, Paul

  reply	other threads:[~2010-04-22 22:05 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-22  9:29 [PATCH 1/5] cgroup: Fix an RCU warning in cgroup_path() Li Zefan
2010-04-22  9:30 ` [PATCH 2/5] cgroup: Fix an RCU warning in alloc_css_id() Li Zefan
2010-04-22 19:55   ` Paul E. McKenney
2010-04-22  9:30 ` [PATCH 3/5] sched: Fix an RCU warning in print_task() Li Zefan
2010-04-22 10:20   ` Peter Zijlstra
2010-04-22 21:12     ` Matt Helsley
2010-04-22 22:05       ` Paul E. McKenney [this message]
2010-04-22 19:56   ` Paul E. McKenney
2010-04-22  9:31 ` [PATCH 4/5] freezer cgroup: Fix an RCU warning in cgroup_freezing_or_frozen() Li Zefan
2010-04-22 12:27   ` Peter Zijlstra
2010-04-22 19:59     ` Paul E. McKenney
2010-04-22 19:59       ` Paul E. McKenney
2010-04-22 20:08       ` Peter Zijlstra
2010-04-23  1:05         ` Li Zefan
2010-04-23  6:47           ` Peter Zijlstra
2010-04-22  9:32 ` [PATCH 5/5] blk-cgroup: Fix an RCU warning in blkiocg_create() Li Zefan
2010-04-22 14:31   ` Vivek Goyal
     [not found]   ` <4BD017AC.1020209-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2010-04-22 19:57     ` Paul E. McKenney
2010-04-22 19:57       ` Paul E. McKenney
2010-05-07  6:56       ` Li Zefan
2010-05-07  6:57         ` Jens Axboe
2010-05-07 14:55           ` Paul E. McKenney
2010-04-22 19:55 ` [PATCH 1/5] cgroup: Fix an RCU warning in cgroup_path() 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=20100422220504.GP2524@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=matthltc@us.ibm.com \
    --cc=menage@google.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.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.