linux-kernel - Re: [PATCH RFC tip/core/rcu 0/28] Preview of RCU changes for 3.3

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]

Message-ID: <20111103045535.GA1957@leaf>
Date:	Wed, 2 Nov 2011 21:55:35 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...ymtl.ca, niv@...ibm.com, tglx@...utronix.de,
	peterz@...radead.org, rostedt@...dmis.org, Valdis.Kletnieks@...edu,
	dhowells@...hat.com, eric.dumazet@...il.com, darren@...art.com,
	patches@...aro.org
Subject: Re: [PATCH RFC tip/core/rcu 0/28] Preview of RCU changes for 3.3

On Wed, Nov 02, 2011 at 01:30:17PM -0700, Paul E. McKenney wrote:
> This patchset permits idle tasks to use RCU read-side critical sections,
> although they are still prohibited between tick_nohz_idle_exit_norcu()
> and tick_nohz_idle_exit_norcu(); makes synchronize_sched_expedited()
> better able to share work among concurrent callers, allows ftrace_dump()
> to be invoked from modules, dumps tracing upon detection of an rcutorture
> failure, detects illegal use of RCU read-side critical sections from
> extended quiescent states, legitimizes the pre-existin use of RCU in the
> idle notifiers, fixes a memory-barrier botch, introduces an SRCU-like bulk
> reference count, improve dynticks entry/exit tracing, further improves
> RCU's ability to allow a given CPU to enter dyntick-idle mode quickly,
> fixes idle-task checks, updates documentation, and additional fixes
> from a still-ongoing top-to-bottom inspection of RCU.  The patches are
> as follows:

I've reviewed all of these patches.  For all of them except those
indicated below:
Reviewed-by: Josh Triplett <josh@...htriplett.org>

> 1.	Strengthen memory barriers used in PowerPC value-returning
> 	atomics and locking primitives.  It is likely that this
> 	commit will be superseded by something from the powerpc
> 	maintainers.  The need for this strengthening was validated
> 	by tooling from Peter Sewell's group at the University of
> 	Cambridge.

As before, I don't have the background on powerpc to provide review on
this one.  However, I trust Peter Sewell's group to have gotten the
details right. :)

> 5.	Document the troubleshooting of lockdep lock-class leaks.

I replied with a few comments and a typo fix.

> 11.	Remove a useless self-awaken when setting up expedited grace
> 	periods, courtesy of Thomas Gleixner and the -rt effort.

Replied with a fix: commit needs splitting.

> 12-17.	Make lockdep-RCU warn when RCU read-side primitives are
> 	invoked from an idle RCU extended quiescent state, mostly
> 	courtesy of Frederic Weisbecker.

Replied to 17 with a minor nit, but Reviewed-by still applies to all
five with or without that nit fixed.

> 18-23.	Separate out the scheduler-clock tick's idea of dyntick
> 	idle from RCU's notion of an idle extended quiescent state, mostly
> 	courtesy of Frederic Weisbecker.  These commits are needed for
> 	Frederic's work to suppress the scheduler-clock tick when there
> 	is but one runnable task on a given CPU.

Very much looking forward to that work.  Any pointer to more information
on tickless-when-one-task?

Replied to patch 19 with some naming comments; the rest seem fine.

> 24.	Introduce a bulk reference count, which is related to SRCU,
> 	but which allows a reference to be acquired in an irq handler
> 	and released by the task that was interrupted.

Replied with comments.

> 27.	Allow CPUs with pending RCU callbacks to enter dyntick-idle
> 	mode.  Beware this commit, as it compiled and passed rcutorture
> 	on the first try, which historically has indicated the presence
> 	of subtle and highly destructive bugs.

Heh.  I reviewed this one particularly carefully, then, but I didn't
find any logic errors.  I did reply with a couple of comments, though.

> 28.	Fix RCU's determination of whether or not it is running in the
> 	context of an idle task.

Replied with concerns.

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