linux-kernel - question about RCU dynticks

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, 04 May 2015 11:59:05 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Paolo Bonzini <pbonzini@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Andy Lutomirski <luto@...capital.net>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, williams@...hat.com,
	Andrew Lutomirski <luto@...nel.org>, fweisbec@...hat.com,
	Peter Zijlstra <peterz@...radead.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: question about RCU dynticks_nesting

On 05/04/2015 05:26 AM, Paolo Bonzini wrote:

> Isn't this racy?
> 
> 	synchronize_rcu CPU		nohz CPU
> 	---------------------------------------------------------
> 					set flag = 0
> 	read flag = 0
> 					return to userspace
> 	set TIF_NOHZ
> 
> and there's no guarantee that TIF_NOHZ is ever processed by the nohz CPU.

Looking at the code some more, a flag is not going to be enough.

An irq can hit while we are in kernel mode, leading to the
task's "rcu active" counter being incremented twice.

However, currently the RCU code seems to use a much more
complex counting scheme, with a different increment for
kernel/task use, and irq use.

This counter seems to be modeled on the task preempt_counter,
where we do care about whether we are in task context, irq
context, or softirq context.

On the other hand, the RCU code only seems to care about
whether or not a CPU is in an extended quiescent state,
or is potentially in an RCU critical section.

Paul, what is the reason for RCU using a complex counter,
instead of a simple increment for each potential kernel/RCU
entry, like rcu_read_lock() does with CONFIG_PREEMPT_RCU
enabled?

In fact, would we be able to simply use tsk->rcu_read_lock_nesting
as an indicator of whether or not we should bother waiting on that
task or CPU when doing synchronize_rcu?

-- 
All rights reversed
--
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/