linux-kernel - Re: [PATCH tip/core/rcu 03/13] rcu: Stop treating in-kernel CPU-bound workloads as errors

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160225094317.GN6356@twins.programming.kicks-ass.net>
Date:	Thu, 25 Feb 2016 10:43:17 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...nel.org,
	jiangshanlai@...il.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
	josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
	dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
	fweisbec@...il.com, oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH tip/core/rcu 03/13] rcu: Stop treating in-kernel
 CPU-bound workloads as errors

On Tue, Feb 23, 2016 at 09:12:40PM -0800, Paul E. McKenney wrote:
> Commit 4a81e8328d379 ("Reduce overhead of cond_resched() checks for RCU")
> handles the error case where a nohz_full loops indefinitely in the kernel
> with the scheduling-clock interrupt disabled.  However, this handling
> includes IPIing the CPU running the offending loop, which is not what
> we want for real-time workloads.  And there are starting to be real-time
> CPU-bound in-kernel workloads, and these must be handled without IPIing
> the CPU, at least not in the common case.  Therefore, this situation can
> no longer be dismissed as an error case.

Do explain. Doing "for (;;) ;" in a kernel RT thread is just as bad for
general system health as is doing the same in userspace.

Also, who runs his RT workload in-kernel ?