Re: [PATCH] rcu: Is it safe to enter an RCU read-side criticalsection?

[Paul E. McKenney]

On Mon, Sep 09, 2013 at 09:21:42AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 15:08:53 +0200
> Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:
> 
> > On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
> 
> > > From reading the context a bit more, it seems that the per cpu value is
> > > more a "per task" value that happens to be using per cpu variables, and
> > > changes on context switches. Is that correct?
> > 
> > Yeah that's probably what confuse so many people. It's indeed at the same
> > time a task state and a per cpu state.
> 
> Especially since the function name itself is "rcu_is_cpu_idle()" which
> tells you it's a cpu state, and not a task state. Why would you care in
> RCU if CPU 1 is idle if you are on CPU 2? The name should be changed.

I could call it rcu_watching_this_cpu(), and rename the current
rcu_watching_this_cpu() to __rcu_watching_this_cpu().

It should be possible to make a straightforward comment that helps.
I will let Frederic take first crack at it.

> > Pretty much like tsk->ti->preempt_count that people now try to implement
> > through a per cpu value.
> 
> Actually, preempt_count is more a CPU state than a task state. When
> preempt_count is set, that CPU can not schedule out the current task.
> It really has nothing to do with the task itself. It's the CPU that
> can't do something. Preempt count should never traverse with a task
> from one CPU to another.

And this is similar to what is happening with rcu_is_cpu_idle().  The
rcu_dynticks.dynticks per-CPU variable cannot transition between zero
and non-zero while a given non-idle task is running.  So what about
the idle tasks?  Well, they run with preemption disabled, so they can
safely access per-CPU variables.

							Thanx, Paul

--
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/