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:   Wed, 11 Jul 2018 07:25:42 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "Hillenbrand, Marius" <mhillenb@...zon.com>
Subject: Re: [RFC] Make need_resched() return true when rcu_urgent_qs
 requested

On Wed, Jul 11, 2018 at 01:58:22PM +0100, David Woodhouse wrote:
> On Wed, 2018-07-11 at 05:51 -0700, Paul E. McKenney wrote:
> > 
> > Interesting.  (I am assuming that the guest is printing these messages,
> > not the host, but please let me know if my assumption is incorrect.)
> 
> No, this is all in the host. When the VMM (qemu, etc.) opens more files
> and has to expand its fd_table, the threads which are currently in
> KVM's vcpu_run() are making synchronize_sched() take multiple seconds.
> 
> > Are the CPUs saturated?  If so, could you please try booting with
> > rcutree.kthread_prio=2?  If that prevents the messages from happening,
> > then I need to put some work into guaranteeing forward progress.
> > Otherwise, I need to figure out why the setting of rcu_urgent_qs is
> > being ignored.
> 
> The CPUs shouldn't be saturated. The guest is fairly much idle. I can
> best reproduce this by starting up the guest and then assigning a new
> PCI device. At that point fairly much nothing is happening at all.

OK, thank you for the information and again apologies for the hassle.
I will do what I should have done long ago and make the relevant addition
to rcutorture.

In the meantime, one workaround is to export rcu_momentary_dyntick_idle()
and to invoke it from within your loop, for example, as enabled by the
(untested, probably does not even build) patch below.

This approach is quite a bit heavier weight than the hoped-for eventual
fix, but it should get this out of the way to allow you to find other
problems in your testing.  ;-)

							Thanx, Paul

> > I will assume the latter for the moment and see if I can spot the
> > problem.

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

diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index b3dbf9502fd0..bbf23e1318a9 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -115,6 +115,7 @@ static inline bool rcu_irq_enter_disabled(void) { return false; }
 static inline void rcu_irq_exit_irqson(void) { }
 static inline void rcu_irq_enter_irqson(void) { }
 static inline void rcu_irq_exit(void) { }
+static inline void rcu_momentary_dyntick_idle(void) { }
 static inline void exit_rcu(void) { }
 #ifdef CONFIG_SRCU
 void rcu_scheduler_starting(void);
diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index 37d6fd3b7ff8..1bec142720dd 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -86,6 +86,7 @@ void rcu_irq_exit(void);
 void rcu_irq_enter_irqson(void);
 void rcu_irq_exit_irqson(void);
 bool rcu_irq_enter_disabled(void);
+void rcu_momentary_dyntick_idle(void);
 
 void exit_rcu(void);
 
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index f9c0ca2ccf0c..da06a52e5e60 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -439,11 +439,12 @@ bool rcu_eqs_special_set(int cpu)
  *
  * The caller must have disabled interrupts.
  */
-static void rcu_momentary_dyntick_idle(void)
+void rcu_momentary_dyntick_idle(void)
 {
 	raw_cpu_write(rcu_dynticks.rcu_need_heavy_qs, false);
 	rcu_dynticks_momentary_idle();
 }
+EXPORT_SYMBOL_GPL(rcu_momentary_dyntick_idle);
 
 /*
  * Note a context switch.  This is a quiescent state for RCU-sched,