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 11:39:05 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	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 11:20:57 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> > It's a bit the same with spinlocks. spinlocks aren't a task synchronization
> > but a CPU synchronization. It's low level. Of course a task can't sleep
> > with a spinlock held (not talking about -rt) so it could be defined as a per
> > task property. But it's just not relevant.
> 
> Again, this is where we get into trouble. No it is not a CPU
> synchronization. We only disable preemption because of implementation
> details. Not the concept. A spin lock is only used to protect critical
> data, and not to disable preemption. Those that use it to disable
> preemption has caused us issues in -rt.
> 
> This is again the problem with confusing implementation with concepts.
> -rt proved that a spin lock has nothing to do with cpu state, nor
> preemption.
> 

Let me expand on this. Note, using a implementation detail from a item
is known as a side effect, and is frowned on when doing so.

In fact, when spin_locks() were created, it was just to point out where
critical sections are that prevent more than one task from accessing
some data at the same time. This was needed for multiple CPUs. This was
done before CONFIG_PREEMPT was even created.

Then Robert Love built on that concept where these same locations
had a characteristic that showed where two tasks can not access the
same data, and used that as preemption points. Points where we can not
be preempted, and let the kernel become preemptible.

Then -rt built further on the concept, and made these locations able to
sleep by removing the areas that could not sleep before (by threading
IRQs).

Again, the concept of a spin lock is not about the CPU or even the
task. It is about accessing some data in a safe way. When we stick to
concepts, we can expand on them as we did with CONFIG_PREEMPT and
CONFIG_PREEMPT_RT. It's when people use side effects (disabled
preemption) that breaks this expansion (like those that use spin_locks
and access per_cpu data).

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