Re: [PATCH tip/core/urgent 1/3] rcu: fix lockdep splat inwake_affine()

[Paul E. McKenney]

On Wed, Jun 16, 2010 at 08:23:11AM +0200, Peter Zijlstra wrote:
> On Tue, 2010-06-15 at 15:29 -0700, Paul E. McKenney wrote:
> > From: Daniel J Blueman <daniel.blueman@xxxxxxxxx>
> > 
> > With 2.6.35-rc1 and your patch in the context below, we still see
> > "include/linux/cgroup.h:534 invoked rcu_dereference_check() without
> > protection!", so need this additional patch:
> > 
> > Acquire read-side RCU lock around task_group() calls, addressing
> > "include/linux/cgroup.h:534 invoked rcu_dereference_check() without
> > protection!" warning.
> 
> Uhm,. this is all just slapping in rcu_read_lock() to make the warning
> go away, without explanation of what and why.
> 
> Its not obvious what the races is, nor how its handled.

Please let me know if my explanation in a recent email covers this.
If so, I will add it to the commit log.  If not, well, back to the
drawing board, I guess.  ;-)

							Thanx, Paul

> > Signed-off-by: Daniel J Blueman <daniel.blueman@xxxxxxxxx>
> > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
> > ---
> >  kernel/sched_fair.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> > index eed35ed..ca56133 100644
> > --- a/kernel/sched_fair.c
> > +++ b/kernel/sched_fair.c
> > @@ -1240,6 +1240,7 @@ static int wake_affine(struct sched_domain *sd, struct task_struct *p, int sync)
> >  	 * effect of the currently running task from the load
> >  	 * of the current CPU:
> >  	 */
> > +	rcu_read_lock();
> >  	if (sync) {
> >  		tg = task_group(current);
> >  		weight = current->se.load.weight;
> > @@ -1249,6 +1250,7 @@ static int wake_affine(struct sched_domain *sd, struct task_struct *p, int sync)
> >  	}
> >  
> >  	tg = task_group(p);
> > +	rcu_read_unlock();
> >  	weight = p->se.load.weight;
> >  
> >  	/*
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/