linux-kernel - Re: [RFC] Make need_resched() return true when rcu_urgent

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, 9 Jul 2018 17:26:32 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     David Woodhouse <dwmw2@...radead.org>, mhillenb@...zon.de,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Make need_resched() return true when rcu_urgent_qs
 requested

On Mon, Jul 09, 2018 at 07:29:32AM -0700, Paul E. McKenney wrote:
> OK, so here are our options:
> 
> 1.	Add the RCU conditional to need_resched(), as David suggests.
> 	Peter has concerns about overhead.
> 
> 2.	Create a new need_resched_rcu_qs() that is to be used when
> 	deciding whether or not to do cond_resched().  This would
> 	exact the overhead only where it is needed, but is one more
> 	thing for people to get wrong.

Also, with the crypto guys checking need_resched() in asm that won't
really work either.

> 3.	Revert my changes to de-emphasize cond_resched_rcu_qs(),
> 	and go back to sprinkling cond_resched_rcu_qs() throughout
> 	the code.  This also is one more thing for people to get wrong,
> 	and might well eventually convert all cond_resched() calls to
> 	cond_resched_rcu_qs(), which sure seems like a failure mode to me.

 4a.	use resched_cpu() more agressive
 4b.	use the tick to set TIF_NEED_RESCHED when it finds rcu_urgent_qs
	(avoids the IPI at the 'cost' of a slight delay in processing)

 5.	make guest mode a quiescent state (like supposedly already done
	for NOHZ_FULL) (but this would not help the crypto guys).

 6.	....

ok I ran out of ideas here I think.


So for PREEMPT the tick can check preempt_count() == 0 and if so, know
it _could_ have rescheduled and advance the qs, right? But since we
don't have a preempt count for !PREEMPT_COUNT kernels this doesn't work.

And thus we need to invoke actual scheduling events and then through the
schedule() callback RCU knows things happened.

4b seems like something worth trying for !PREEMPT kernels I suppose