All of lore.kernel.org
 help / color / mirror / Atom feed
* Fix for 10-second delay bug for -stable
@ 2018-10-31 22:45 Paul E. McKenney
  0 siblings, 0 replies; only message in thread
From: Paul E. McKenney @ 2018-10-31 22:45 UTC (permalink / raw)
  To: mhillenb, dwmw2; +Cc: peterz, linux-kernel

Hello!

I have lightly tested the following backport of 92aa39e9dc77 ("rcu:
Make need_resched() respond to urgent RCU-QS needs") on v4.12-v4.19.
Does it look reasonable from your viewpoint?

If I don't hear otherwise, I will send it along to -stable at the end
of this coming weekend, Pacific Time.

This patch does not apply to v4.11 and earlier.  I will therefore
ignore those releases unless someone reproduces the problem on them.

							Thanx, Paul

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

commit 0a555b6d58f80dcd93a116c5b197208aeaf9f7ef
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Mon Jul 9 13:47:30 2018 -0700

    rcu: Make need_resched() respond to urgent RCU-QS needs
    
    commit 92aa39e9dc77 upstream.
    
    The per-CPU rcu_dynticks.rcu_urgent_qs variable communicates an urgent
    need for an RCU quiescent state from the force-quiescent-state processing
    within the grace-period kthread to context switches and to cond_resched().
    Unfortunately, such urgent needs are not communicated to need_resched(),
    which is sometimes used to decide when to invoke cond_resched(), for
    but one example, within the KVM vcpu_run() function.  As of v4.15, this
    can result in synchronize_sched() being delayed by up to ten seconds,
    which can be problematic, to say nothing of annoying.
    
    This commit therefore checks rcu_dynticks.rcu_urgent_qs from within
    rcu_check_callbacks(), which is invoked from the scheduling-clock
    interrupt handler.  If the current task is not an idle task and is
    not executing in usermode, a context switch is forced, and either way,
    the rcu_dynticks.rcu_urgent_qs variable is set to false.  If the current
    task is an idle task, then RCU's dyntick-idle code will detect the
    quiescent state, so no further action is required.  Similarly, if the
    task is executing in usermode, other code in rcu_check_callbacks() and
    its called functions will report the corresponding quiescent state.
    
    Reported-by: Marius Hillenbrand <mhillenb@amazon.de>
    Reported-by: David Woodhouse <dwmw2@infradead.org>
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    [ paulmck: Backported to make patch apply cleanly on older versions. ]
    Tested-by: Marius Hillenbrand <mhillenb@amazon.de>
    Cc: <stable@vger.kernel.org> # 4.12.x - 4.19.x

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0b760c1369f7..15301ed19da6 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2662,6 +2662,15 @@ void rcu_check_callbacks(int user)
 		rcu_bh_qs();
 	}
 	rcu_preempt_check_callbacks();
+	/* The load-acquire pairs with the store-release setting to true. */
+	if (smp_load_acquire(this_cpu_ptr(&rcu_dynticks.rcu_urgent_qs))) {
+		/* Idle and userspace execution already are quiescent states. */
+		if (!rcu_is_cpu_rrupt_from_idle() && !user) {
+			set_tsk_need_resched(current);
+			set_preempt_need_resched();
+		}
+		__this_cpu_write(rcu_dynticks.rcu_urgent_qs, false);
+	}
 	if (rcu_pending())
 		invoke_rcu_core();
 


^ permalink raw reply related	[flat|nested] only message in thread

only message in thread, other threads:[~2018-10-31 22:45 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-10-31 22:45 Fix for 10-second delay bug for -stable Paul E. McKenney

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.