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]
Date:	Tue, 19 Jul 2011 17:17:38 -0700
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, 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, greearb@...delatech.com, edt@....ca
Subject: [PATCH rcu/urgent 0/6] Fixes for RCU/scheduler/irq-threads
 trainwreck

Hello!

This patch set contains fixes for a trainwreck involving RCU, the
scheduler, and threaded interrupts.  This trainwreck involved RCU failing
to properly protect one of its bit fields, use of RCU by the scheduler
from portions of irq_exit() where in_irq() returns false, uses of the
scheduler by RCU colliding with uses of RCU by the scheduler, threaded
interrupts exercising the problematic portions of irq_exit() more heavily,
and so on.  The patches are as follows:

1.	Properly protect current->rcu_read_unlock_special().
	Lack of protection was causing RCU to recurse on itself, which
	in turn resulted in deadlocks involving RCU and the scheduler.
	This affects only RCU_BOOST=y configurations.
2.	Streamline code produced by __rcu_read_unlock().  This one is
	an innocent bystander that is being carried due to conflicts
	with other patches.  (A later version will likely merge it
	with #3 below.)
3.	Make __rcu_read_unlock() delay counting the per-task
	->rcu_read_lock_nesting variable to zero until all cleanup for the
	just-ended RCU read-side critical section has completed.  This
	prevents a number of other cases that could result in deadlock
	due to self recursion.	This affects only TREE_PREEMPT_RCU=y
	configurations.
4.	Make scheduler_ipi() correctly identify itself as being
	in_irq() when it needs to do anything that might involve RCU,
	thus enabling RCU to avoid yet another class of potential
	self-recursions and deadlocks.	This affects PREEMPT_RCU=y
	configurations.
5.	Make irq_exit() inform RCU when it is invoking the scheduler
	in situations where in_irq() would return false, thus
	allowing RCU to correctly avoid self-recursion.  This affects
	TREE_PREEMPT_RCU=y configurations.
6.	Make __lock_task_sighand() execute the entire RCU read-side
	critical section with irqs disabled.  (An experimental patch at
	http://marc.info/?l=linux-kernel&m=131110647222185 might possibly
	make it legal to have an RCU read-side critical section where
	the rcu_read_unlock() is executed with interrupts disabled,
	but where some protion of the RCU read-side critical section
	was preemptible.)  This affects TREE_PREEMPT_RCU=y configurations.

TINY_PREEMPT_RCU will also need a few of these changes, but in the
meantime this patch stack helps organize things better for testing.
These are also available from the following subject-to-rebase git branch:

git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git rcu/urgent

							Thanx, Paul

------------------------------------------------------------------------

 b/include/linux/sched.h   |    3 +++
 b/kernel/rcutree_plugin.h |    3 ++-
 b/kernel/sched.c          |   44 ++++++++++++++++++++++++++++++++++++++------
 b/kernel/signal.c         |   16 +++++++++++-----
 b/kernel/softirq.c        |   12 ++++++++++--
 kernel/rcutree_plugin.h   |   45 ++++++++++++++++++++++++++++++++-------------
 6 files changed, 96 insertions(+), 27 deletions(-)
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ