linux-kernel - Re: [PATCH RFC tip/core/rcu 11/11] rcu: move TREE

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:	Wed, 23 Feb 2011 13:38:13 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	Christoph Lameter <cl@...ux.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	josh@...htriplett.org, niv@...ibm.com, tglx@...utronix.de,
	peterz@...radead.org, Valdis.Kletnieks@...edu, dhowells@...hat.com,
	eric.dumazet@...il.com, darren@...art.com,
	"Paul E. McKenney" <paul.mckenney@...aro.org>
Subject: Re: [PATCH RFC tip/core/rcu 11/11] rcu: move TREE_RCU from softirq
	to kthread

* Steven Rostedt (rostedt@...dmis.org) wrote:
> On Wed, 2011-02-23 at 11:34 -0600, Christoph Lameter wrote:
> 
> > > > True, but we could also argue that the multiple checks for being preempt
> > > > can also be an issue.
> > >
> > > At least on x86 preemption don't actually need to be disabled: selection
> > > of the right per-cpu memory location is done atomically with the rest of
> > > the instruction by the segment selector.
> > 
> > Right.
> 
> But a test still needs to be made. Because three access of this_cpu_*()
> that gets preempted and scheduled on another CPU can access a different
> CPU var for each access. This does not matter how atomic the
> this_cpu_*() code is.
> 
> IOW, the use of this_cpu_*() without preemption disabled is 99% of the
> time a bug.

Agreed. Unless the algorithm is carefully crafted to allow being
migrated in between the ops (which is a non-trivial exercise), these
would be bugs.

As far as I am aware, there are at least two cases where leaving preempt
enabled makes sense: if we use cmpxchg or add_return, these can be
followed by tests on the return value and allow creation of preemptable
fast-paths that allow migration between the per-cpu op and the following
test (useful to keep per-cpu counters that are summed into global
counters when some power-of-2 threshold value is reached in the
low-order bits). Using cpuid field within atomically updated variable
can also allow detection of migration between the operations. In
addition, we can add the trivial single update case, but this really
does not count as a non-trivial algorithm.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/