[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Sep 2013 08:55:04 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Eric Dumazet <eric.dumazet@...il.com>,
linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
dipankar@...ibm.com, akpm@...ux-foundation.org,
mathieu.desnoyers@...icios.com, josh@...htriplett.org,
niv@...ibm.com, tglx@...utronix.de, dhowells@...hat.com,
edumazet@...gle.com, darren@...art.com, sbw@....edu
Subject: Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical
section?
On Mon, 9 Sep 2013 14:45:49 +0200
Frederic Weisbecker <fweisbec@...il.com> wrote:
> > This just proves that the caller of rcu_is_cpu_idle() must disable
> > preemption itself for the entire time that it needs to use the result
> > of rcu_is_cpu_idle().
>
> Sorry, I don't understand your point here. What's wrong with checking the
> ret from another CPU?
Hmm, OK, this is why that code is in desperate need of a comment.
>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?
Anyway, it requires a comment to explain that we are not checking the
CPU state, but really the current task state, otherwise that 'ret'
value wouldn't travel with the task, but would stick with the CPU.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists