linux-kernel - Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 9 Sep 2013 09:21:42 -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 15:08:53 +0200
Frederic Weisbecker <fweisbec@...il.com> 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.

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

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