linux-kernel - [PATCH RFC tip/core/rcu 0/18] rcu: simplify race conditions, add checking

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-next>] [day] [month] [year] [list]

Message-ID: <20091215230213.GA9093@linux.vnet.ibm.com>
Date:	Tue, 15 Dec 2009 15:02:13 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	linux-kernel@...r.kernel.org
Cc:	mingo@...e.hu, laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...ymtl.ca,
	josh@...htriplett.org, dvhltc@...ibm.com, niv@...ibm.com,
	tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
	Valdis.Kletnieks@...edu, dhowells@...hat.com
Subject: [PATCH RFC tip/core/rcu 0/18] rcu: simplify race conditions, add
	checking

Hello!

This is just a sneak preview of RCU patches that I have in flight, not
yet for inclusion.

Patches 1-10 simplify TREE_RCU's (and TREE_PREEMPT_RCU's) race conditions
by prohibiting grace periods from starting while force_quiescent_state()
is active.  Patch 10 maintains grace-period latency by the simple
expedient of having force_quiescent_state() check to see if someone
wanted to start a grace period, and, if so, starting one on their behalf.

Patch 11 adds parameters to rcutorture to allow testing with extremely
rapid re-invocations of force_quiescent_state() -- microseconds rather
than the previous milliseconds.

Patch 12 makes the RCU and rcutorture entries of the MAINTAINERS file
call out the correct source files, which have changed due to the recent
re-implementation.

Patches 13-18 add debugging checks, so that an rcu_dereference(p)
can now be rcu_dereference(p, rcu_read_lock_held()), which
will complain if invoked outside of an RCU read-side critical
section when CONFIG_PROVE_LOCKING is specified.  There are
also rcu_read_lock_bh_held(), rcu_read_lock_sched_held(), and
srcu_read_lock_held() for the other flavors of RCU.

One can also do something like:

	p = rcu_dereference_check(gp, rcu_read_lock_bh_held() ||
				  lockdep_is_held(my_lock));

to handle the case where either the access must either be protected
by RCU-bh or by my_lock.

Again, strictly FYI, not yet for inclusion.

							Thanx, Paul
--
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/