From: Greg Kroah-Hartman Date: Wed, 10 Oct 2012 00:25:24 +0000 (+0900) Subject: 3.0-stable patches X-Git-Tag: v3.0.46~21 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=87dd63a7940b139468476d6f3f7c0b80618ae12d;p=thirdparty%2Fkernel%2Fstable-queue.git 3.0-stable patches added patches: rcu-fix-day-one-dyntick-idle-stall-warning-bug.patch --- diff --git a/queue-3.0/rcu-fix-day-one-dyntick-idle-stall-warning-bug.patch b/queue-3.0/rcu-fix-day-one-dyntick-idle-stall-warning-bug.patch new file mode 100644 index 00000000000..1d807db4282 --- /dev/null +++ b/queue-3.0/rcu-fix-day-one-dyntick-idle-stall-warning-bug.patch @@ -0,0 +1,84 @@ +From a10d206ef1a83121ab7430cb196e0376a7145b22 Mon Sep 17 00:00:00 2001 +From: "Paul E. McKenney" +Date: Sat, 22 Sep 2012 13:55:30 -0700 +Subject: rcu: Fix day-one dyntick-idle stall-warning bug + +From: "Paul E. McKenney" + +commit a10d206ef1a83121ab7430cb196e0376a7145b22 upstream. + +Each grace period is supposed to have at least one callback waiting +for that grace period to complete. However, if CONFIG_NO_HZ=n, an +extra callback-free grace period is no big problem -- it will chew up +a tiny bit of CPU time, but it will complete normally. In contrast, +CONFIG_NO_HZ=y kernels have the potential for all the CPUs to go to +sleep indefinitely, in turn indefinitely delaying completion of the +callback-free grace period. Given that nothing is waiting on this grace +period, this is also not a problem. + +That is, unless RCU CPU stall warnings are also enabled, as they are +in recent kernels. In this case, if a CPU wakes up after at least one +minute of inactivity, an RCU CPU stall warning will result. The reason +that no one noticed until quite recently is that most systems have enough +OS noise that they will never remain absolutely idle for a full minute. +But there are some embedded systems with cut-down userspace configurations +that consistently get into this situation. + +All this begs the question of exactly how a callback-free grace period +gets started in the first place. This can happen due to the fact that +CPUs do not necessarily agree on which grace period is in progress. +If a CPU still believes that the grace period that just completed is +still ongoing, it will believe that it has callbacks that need to wait for +another grace period, never mind the fact that the grace period that they +were waiting for just completed. This CPU can therefore erroneously +decide to start a new grace period. Note that this can happen in +TREE_RCU and TREE_PREEMPT_RCU even on a single-CPU system: Deadlock +considerations mean that the CPU that detected the end of the grace +period is not necessarily officially informed of this fact for some time. + +Once this CPU notices that the earlier grace period completed, it will +invoke its callbacks. It then won't have any callbacks left. If no +other CPU has any callbacks, we now have a callback-free grace period. + +This commit therefore makes CPUs check more carefully before starting a +new grace period. This new check relies on an array of tail pointers +into each CPU's list of callbacks. If the CPU is up to date on which +grace periods have completed, it checks to see if any callbacks follow +the RCU_DONE_TAIL segment, otherwise it checks to see if any callbacks +follow the RCU_WAIT_TAIL segment. The reason that this works is that +the RCU_WAIT_TAIL segment will be promoted to the RCU_DONE_TAIL segment +as soon as the CPU is officially notified that the old grace period +has ended. + +This change is to cpu_needs_another_gp(), which is called in a number +of places. The only one that really matters is in rcu_start_gp(), where +the root rcu_node structure's ->lock is held, which prevents any +other CPU from starting or completing a grace period, so that the +comparison that determines whether the CPU is missing the completion +of a grace period is stable. + +Reported-by: Becky Bruce +Reported-by: Subodh Nijsure +Reported-by: Paul Walmsley +Signed-off-by: Paul E. McKenney +Signed-off-by: Paul E. McKenney +Tested-by: Paul Walmsley # OMAP3730, OMAP4430 +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/rcutree.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/kernel/rcutree.c ++++ b/kernel/rcutree.c +@@ -283,7 +283,9 @@ cpu_has_callbacks_ready_to_invoke(struct + static int + cpu_needs_another_gp(struct rcu_state *rsp, struct rcu_data *rdp) + { +- return *rdp->nxttail[RCU_DONE_TAIL] && !rcu_gp_in_progress(rsp); ++ return *rdp->nxttail[RCU_DONE_TAIL + ++ ACCESS_ONCE(rsp->completed) != rdp->completed] && ++ !rcu_gp_in_progress(rsp); + } + + /* diff --git a/queue-3.0/series b/queue-3.0/series index c90bd60b60b..6d0c96e35d8 100644 --- a/queue-3.0/series +++ b/queue-3.0/series @@ -57,3 +57,4 @@ alsa-usb-support-for-original-xbox-communicator.patch drm-radeon-only-adjust-default-clocks-on-ni-gpus.patch drm-radeon-add-msi-quirk-for-gateway-rs690.patch drm-radeon-force-msis-on-rs690-asics.patch +rcu-fix-day-one-dyntick-idle-stall-warning-bug.patch