Hi,
Changes since v1:
- Fixed preempt handling in alpha idle loop
- added ack from Geert
- fixed stable email address, sorry :-/
This time I built tested everywhere but: h8300 (compiler internal error),
and mn10300, parisc, score (cross compilers not available in
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
For testing, you can pull from:
git://github.com/fweisbec/linux-dynticks.git
rcu/idle-fix-v2
Thanks.
Frederic Weisbecker (11):
alpha: Fix preemption handling in idle loop
alpha: Add missing RCU idle APIs on idle loop
cris: Add missing RCU idle APIs on idle loop
frv: Add missing RCU idle APIs on idle loop
h8300: Add missing RCU idle APIs on idle loop
m32r: Add missing RCU idle APIs on idle loop
m68k: Add missing RCU idle APIs on idle loop
mn10300: Add missing RCU idle APIs on idle loop
parisc: Add missing RCU idle APIs on idle loop
score: Add missing RCU idle APIs on idle loop
xtensa: Add missing RCU idle APIs on idle loop
arch/alpha/kernel/process.c | 6 +++++-
arch/alpha/kernel/smp.c | 1 +
arch/cris/kernel/process.c | 3 +++
arch/frv/kernel/process.c | 3 +++
arch/h8300/kernel/process.c | 3 +++
arch/m32r/kernel/process.c | 3 +++
arch/m68k/kernel/process.c | 3 +++
arch/mn10300/kernel/process.c | 3 +++
arch/parisc/kernel/process.c | 3 +++
arch/score/kernel/process.c | 4 +++-
arch/xtensa/kernel/process.c | 3 +++
11 files changed, 33 insertions(+), 2 deletions(-)
--
1.7.5.4
In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.
So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.
This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.
Add this missing pair of calls in the Alpha's idle loop.
Reported-by: Paul E. McKenney <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Richard Henderson <[email protected]>
Cc: Ivan Kokshaysky <[email protected]>
Cc: Matt Turner <[email protected]>
Cc: alpha <[email protected]>
Cc: Paul E. McKenney <[email protected]>
Cc: Michael Cree <[email protected]>
Cc: 3.2.x.. <[email protected]>
---
arch/alpha/kernel/process.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index eac5e01..eb9558c 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -28,6 +28,7 @@
#include <linux/tty.h>
#include <linux/console.h>
#include <linux/slab.h>
+#include <linux/rcupdate.h>
#include <asm/reg.h>
#include <asm/uaccess.h>
@@ -54,9 +55,11 @@ cpu_idle(void)
/* FIXME -- EV6 and LCA45 know how to power down
the CPU. */
+ rcu_idle_enter();
while (!need_resched())
cpu_relax();
+ rcu_idle_exit();
schedule_preempt_disabled();
}
}
--
1.7.5.4
In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.
So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.
This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.
Add this missing pair of calls in the m32r's idle loop.
Reported-by: Paul E. McKenney <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Hirokazu Takata <[email protected]>
Cc: 3.2.x.. <[email protected]>
Cc: Paul E. McKenney <[email protected]>
---
arch/m32r/kernel/process.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/m32r/kernel/process.c b/arch/m32r/kernel/process.c
index 3a4a32b2..384e63f 100644
--- a/arch/m32r/kernel/process.c
+++ b/arch/m32r/kernel/process.c
@@ -26,6 +26,7 @@
#include <linux/ptrace.h>
#include <linux/unistd.h>
#include <linux/hardirq.h>
+#include <linux/rcupdate.h>
#include <asm/io.h>
#include <asm/uaccess.h>
@@ -82,6 +83,7 @@ void cpu_idle (void)
{
/* endless idle loop with no priority at all */
while (1) {
+ rcu_idle_enter();
while (!need_resched()) {
void (*idle)(void) = pm_idle;
@@ -90,6 +92,7 @@ void cpu_idle (void)
idle();
}
+ rcu_idle_exit();
schedule_preempt_disabled();
}
}
--
1.7.5.4
In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.
So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.
This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.
Add this missing pair of calls in the Cris's idle loop.
Reported-by: Paul E. McKenney <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Mikael Starvik <[email protected]>
Cc: Jesper Nilsson <[email protected]>
Cc: Cris <[email protected]>
Cc: 3.2.x.. <[email protected]>
Cc: Paul E. McKenney <[email protected]>
---
arch/cris/kernel/process.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/cris/kernel/process.c b/arch/cris/kernel/process.c
index 66fd017..7f65be6 100644
--- a/arch/cris/kernel/process.c
+++ b/arch/cris/kernel/process.c
@@ -25,6 +25,7 @@
#include <linux/elfcore.h>
#include <linux/mqueue.h>
#include <linux/reboot.h>
+#include <linux/rcupdate.h>
//#define DEBUG
@@ -74,6 +75,7 @@ void cpu_idle (void)
{
/* endless idle loop with no priority at all */
while (1) {
+ rcu_idle_enter();
while (!need_resched()) {
void (*idle)(void);
/*
@@ -86,6 +88,7 @@ void cpu_idle (void)
idle = default_idle;
idle();
}
+ rcu_idle_exit();
schedule_preempt_disabled();
}
}
--
1.7.5.4
In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.
So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.
This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.
Add this missing pair of calls in the mn10300's idle loop.
Reported-by: Paul E. McKenney <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: David Howells <[email protected]>
Cc: Koichi Yasutake <[email protected]>
Cc: 3.2.x.. <[email protected]>
Cc: Paul E. McKenney <[email protected]>
---
arch/mn10300/kernel/process.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/mn10300/kernel/process.c b/arch/mn10300/kernel/process.c
index 7dab0cd..e9cceba 100644
--- a/arch/mn10300/kernel/process.c
+++ b/arch/mn10300/kernel/process.c
@@ -25,6 +25,7 @@
#include <linux/err.h>
#include <linux/fs.h>
#include <linux/slab.h>
+#include <linux/rcupdate.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
#include <asm/io.h>
@@ -107,6 +108,7 @@ void cpu_idle(void)
{
/* endless idle loop with no priority at all */
for (;;) {
+ rcu_idle_enter();
while (!need_resched()) {
void (*idle)(void);
@@ -121,6 +123,7 @@ void cpu_idle(void)
}
idle();
}
+ rcu_idle_exit();
schedule_preempt_disabled();
}
--
1.7.5.4
In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.
So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.
This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.
Add this missing pair of calls in the xtensa's idle loop.
Reported-by: Paul E. McKenney <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Chris Zankel <[email protected]>
Cc: 3.2.x.. <[email protected]>
Cc: Paul E. McKenney <[email protected]>
---
arch/xtensa/kernel/process.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/xtensa/kernel/process.c b/arch/xtensa/kernel/process.c
index 2c8d6a3..bc44311 100644
--- a/arch/xtensa/kernel/process.c
+++ b/arch/xtensa/kernel/process.c
@@ -31,6 +31,7 @@
#include <linux/mqueue.h>
#include <linux/fs.h>
#include <linux/slab.h>
+#include <linux/rcupdate.h>
#include <asm/pgtable.h>
#include <asm/uaccess.h>
@@ -110,8 +111,10 @@ void cpu_idle(void)
/* endless idle loop with no priority at all */
while (1) {
+ rcu_idle_enter();
while (!need_resched())
platform_idle();
+ rcu_idle_exit();
schedule_preempt_disabled();
}
}
--
1.7.5.4
In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.
So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.
This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.
Add this missing pair of calls in the scores's idle loop.
Reported-by: Paul E. McKenney <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Chen Liqin <[email protected]>
Cc: Lennox Wu <[email protected]>
Cc: 3.2.x.. <[email protected]>
Cc: Paul E. McKenney <[email protected]>
---
arch/score/kernel/process.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/score/kernel/process.c b/arch/score/kernel/process.c
index 2707023..637970c 100644
--- a/arch/score/kernel/process.c
+++ b/arch/score/kernel/process.c
@@ -27,6 +27,7 @@
#include <linux/reboot.h>
#include <linux/elfcore.h>
#include <linux/pm.h>
+#include <linux/rcupdate.h>
void (*pm_power_off)(void);
EXPORT_SYMBOL(pm_power_off);
@@ -50,9 +51,10 @@ void __noreturn cpu_idle(void)
{
/* endless idle loop with no priority at all */
while (1) {
+ rcu_idle_enter();
while (!need_resched())
barrier();
-
+ rcu_idle_exit();
schedule_preempt_disabled();
}
}
--
1.7.5.4
In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.
So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.
This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.
Add this missing pair of calls in the parisc's idle loop.
Reported-by: Paul E. McKenney <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: James E.J. Bottomley <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Parisc <[email protected]>
Cc: 3.2.x.. <[email protected]>
Cc: Paul E. McKenney <[email protected]>
---
arch/parisc/kernel/process.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
index d4b94b3..c54a4db 100644
--- a/arch/parisc/kernel/process.c
+++ b/arch/parisc/kernel/process.c
@@ -48,6 +48,7 @@
#include <linux/unistd.h>
#include <linux/kallsyms.h>
#include <linux/uaccess.h>
+#include <linux/rcupdate.h>
#include <asm/io.h>
#include <asm/asm-offsets.h>
@@ -69,8 +70,10 @@ void cpu_idle(void)
/* endless idle loop with no priority at all */
while (1) {
+ rcu_idle_enter();
while (!need_resched())
barrier();
+ rcu_idle_exit();
schedule_preempt_disabled();
check_pgt_cache();
}
--
1.7.5.4
In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.
So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.
This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.
Add this missing pair of calls in the m68k's idle loop.
Reported-by: Paul E. McKenney <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Cc: m68k <[email protected]>
Cc: 3.2.x.. <[email protected]>
Cc: Paul E. McKenney <[email protected]>
---
arch/m68k/kernel/process.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/m68k/kernel/process.c b/arch/m68k/kernel/process.c
index c488e3c..ac2892e 100644
--- a/arch/m68k/kernel/process.c
+++ b/arch/m68k/kernel/process.c
@@ -25,6 +25,7 @@
#include <linux/reboot.h>
#include <linux/init_task.h>
#include <linux/mqueue.h>
+#include <linux/rcupdate.h>
#include <asm/uaccess.h>
#include <asm/traps.h>
@@ -75,8 +76,10 @@ void cpu_idle(void)
{
/* endless idle loop with no priority at all */
while (1) {
+ rcu_idle_enter();
while (!need_resched())
idle();
+ rcu_idle_exit();
schedule_preempt_disabled();
}
}
--
1.7.5.4
In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.
So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.
This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.
Add this missing pair of calls in the Frv's idle loop.
Reported-by: Paul E. McKenney <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: David Howells <[email protected]>
Cc: 3.2.x.. <[email protected]>
Cc: Paul E. McKenney <[email protected]>
---
arch/frv/kernel/process.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/frv/kernel/process.c b/arch/frv/kernel/process.c
index ff95f50..2eb7fa5 100644
--- a/arch/frv/kernel/process.c
+++ b/arch/frv/kernel/process.c
@@ -25,6 +25,7 @@
#include <linux/reboot.h>
#include <linux/interrupt.h>
#include <linux/pagemap.h>
+#include <linux/rcupdate.h>
#include <asm/asm-offsets.h>
#include <asm/uaccess.h>
@@ -69,12 +70,14 @@ void cpu_idle(void)
{
/* endless idle loop with no priority at all */
while (1) {
+ rcu_idle_enter();
while (!need_resched()) {
check_pgt_cache();
if (!frv_dma_inprogress && idle)
idle();
}
+ rcu_idle_exit();
schedule_preempt_disabled();
}
--
1.7.5.4
In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.
So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.
This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.
Add this missing pair of calls in the h8300's idle loop.
Reported-by: Paul E. McKenney <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: 3.2.x.. <[email protected]>
Cc: Paul E. McKenney <[email protected]>
---
arch/h8300/kernel/process.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/h8300/kernel/process.c b/arch/h8300/kernel/process.c
index 0e9c315..f153ed1 100644
--- a/arch/h8300/kernel/process.c
+++ b/arch/h8300/kernel/process.c
@@ -36,6 +36,7 @@
#include <linux/reboot.h>
#include <linux/fs.h>
#include <linux/slab.h>
+#include <linux/rcupdate.h>
#include <asm/uaccess.h>
#include <asm/traps.h>
@@ -78,8 +79,10 @@ void (*idle)(void) = default_idle;
void cpu_idle(void)
{
while (1) {
+ rcu_idle_enter();
while (!need_resched())
idle();
+ rcu_idle_exit();
schedule_preempt_disabled();
}
}
--
1.7.5.4
cpu_idle() is called on the boot CPU by the init code with
preemption disabled. But the cpu_idle() function in alpha
doesn't handle this when it calls schedule() directly.
Fix it by converting it into schedule_preempt_disabled().
Also disable preemption before calling cpu_idle() from
secondary CPU entry code to stay consistent with this
state.
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Richard Henderson<[email protected]>
Cc: Ivan Kokshaysky <[email protected]>
Cc: Matt Turner <[email protected]>
Cc: alpha <[email protected]>
Cc: Paul E. McKenney <[email protected]>
Cc: Michael Cree <[email protected]>
---
arch/alpha/kernel/process.c | 3 ++-
arch/alpha/kernel/smp.c | 1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 153d3fc..eac5e01 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -56,7 +56,8 @@ cpu_idle(void)
while (!need_resched())
cpu_relax();
- schedule();
+
+ schedule_preempt_disabled();
}
}
diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c
index 35ddc02..a41ad90 100644
--- a/arch/alpha/kernel/smp.c
+++ b/arch/alpha/kernel/smp.c
@@ -166,6 +166,7 @@ smp_callin(void)
DBGS(("smp_callin: commencing CPU %d current %p active_mm %p\n",
cpuid, current, current->active_mm));
+ preempt_disable();
/* Do nothing. */
cpu_idle();
}
--
1.7.5.4
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
> Hi,
>
> Changes since v1:
>
> - Fixed preempt handling in alpha idle loop
> - added ack from Geert
> - fixed stable email address, sorry :-/
>
> This time I built tested everywhere but: h8300 (compiler internal error),
> and mn10300, parisc, score (cross compilers not available in
> ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
>
> For testing, you can pull from:
>
> git://github.com/fweisbec/linux-dynticks.git
> rcu/idle-fix-v2
>
> Thanks.
I have queued these on -rcu branch rcu/idle:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
This problem has been in place since 3.3, so it is hard to argue that
it is a regression for this merge window. I have therefore queued it
for 3.7.
Thanx, Paul
> Frederic Weisbecker (11):
> alpha: Fix preemption handling in idle loop
> alpha: Add missing RCU idle APIs on idle loop
> cris: Add missing RCU idle APIs on idle loop
> frv: Add missing RCU idle APIs on idle loop
> h8300: Add missing RCU idle APIs on idle loop
> m32r: Add missing RCU idle APIs on idle loop
> m68k: Add missing RCU idle APIs on idle loop
> mn10300: Add missing RCU idle APIs on idle loop
> parisc: Add missing RCU idle APIs on idle loop
> score: Add missing RCU idle APIs on idle loop
> xtensa: Add missing RCU idle APIs on idle loop
>
> arch/alpha/kernel/process.c | 6 +++++-
> arch/alpha/kernel/smp.c | 1 +
> arch/cris/kernel/process.c | 3 +++
> arch/frv/kernel/process.c | 3 +++
> arch/h8300/kernel/process.c | 3 +++
> arch/m32r/kernel/process.c | 3 +++
> arch/m68k/kernel/process.c | 3 +++
> arch/mn10300/kernel/process.c | 3 +++
> arch/parisc/kernel/process.c | 3 +++
> arch/score/kernel/process.c | 4 +++-
> arch/xtensa/kernel/process.c | 3 +++
> 11 files changed, 33 insertions(+), 2 deletions(-)
>
> --
> 1.7.5.4
>
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
> On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
> > Hi,
> >
> > Changes since v1:
> >
> > - Fixed preempt handling in alpha idle loop
> > - added ack from Geert
> > - fixed stable email address, sorry :-/
> >
> > This time I built tested everywhere but: h8300 (compiler internal error),
> > and mn10300, parisc, score (cross compilers not available in
> > ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
> >
> > For testing, you can pull from:
> >
> > git://github.com/fweisbec/linux-dynticks.git
> > rcu/idle-fix-v2
> >
> > Thanks.
>
> I have queued these on -rcu branch rcu/idle:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>
> This problem has been in place since 3.3, so it is hard to argue that
> it is a regression for this merge window. I have therefore queued it
> for 3.7.
I don't follow that; I would expect any serious bug fix (serious enough
for a stable update) to be acceptable for 3.6 at this point.
If the regression occurred in 3.3, then the cc lines should be something
like:
Cc: <[email protected]> # 3.3+
and not the current:
Cc: 3.2.x.. <[email protected]>
(Note, version annotations should be on the right of the address, not in
the 'real name' position on the left.)
Ben.
--
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.
On 25/08/12 13:19, Ben Hutchings wrote:
> On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
>> On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
>>> Hi,
>>>
>>> Changes since v1:
>>>
>>> - Fixed preempt handling in alpha idle loop
>>> - added ack from Geert
>>> - fixed stable email address, sorry :-/
>>>
>>> This time I built tested everywhere but: h8300 (compiler internal error),
>>> and mn10300, parisc, score (cross compilers not available in
>>> ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
>>>
>>> For testing, you can pull from:
>>>
>>> git://github.com/fweisbec/linux-dynticks.git
>>> rcu/idle-fix-v2
>>>
>>> Thanks.
>>
>> I have queued these on -rcu branch rcu/idle:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>>
>> This problem has been in place since 3.3, so it is hard to argue that
>> it is a regression for this merge window. I have therefore queued it
>> for 3.7.
>
> I don't follow that; I would expect any serious bug fix (serious enough
> for a stable update) to be acceptable for 3.6 at this point.
>
> If the regression occurred in 3.3, then the cc lines should be something
> like:
>
> Cc: <[email protected]> # 3.3+
>
> and not the current:
>
> Cc: 3.2.x.. <[email protected]>
The Alpha patches fix an even earlier regression resulting in RCU CPU
stalls on an SMP kernel built for generic Alpha (which includes the
current Debian 3.2-alpha-smp kernel) and renders the kernel pretty much
unuseable. I've only tested the two alpha patches together but maybe
just the first patch (1/11 alpha: Fix preemption handling in idle loop)
might be needed to fix the problem in 3.2. I'll test and let you know.
Cheers
Michael.
On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
> On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
> > On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
> > > Hi,
> > >
> > > Changes since v1:
> > >
> > > - Fixed preempt handling in alpha idle loop
> > > - added ack from Geert
> > > - fixed stable email address, sorry :-/
> > >
> > > This time I built tested everywhere but: h8300 (compiler internal error),
> > > and mn10300, parisc, score (cross compilers not available in
> > > ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
> > >
> > > For testing, you can pull from:
> > >
> > > git://github.com/fweisbec/linux-dynticks.git
> > > rcu/idle-fix-v2
> > >
> > > Thanks.
> >
> > I have queued these on -rcu branch rcu/idle:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> >
> > This problem has been in place since 3.3, so it is hard to argue that
> > it is a regression for this merge window. I have therefore queued it
> > for 3.7.
>
> I don't follow that; I would expect any serious bug fix (serious enough
> for a stable update) to be acceptable for 3.6 at this point.
OK, if any of the arch maintainers wishes to submit the patch to 3.6,
they are free to do so -- just let me know and I will drop the patch from
my tree.
That said, all this does is cause spurious warnings to be printed, so
not sure it really qualifies as serious. But I am happy to leave that
decision with the individual arch maintainers -- it is their arch,
after all, so their decision.
Thanx, Paul
> If the regression occurred in 3.3, then the cc lines should be something
> like:
>
> Cc: <[email protected]> # 3.3+
>
> and not the current:
>
> Cc: 3.2.x.. <[email protected]>
>
> (Note, version annotations should be on the right of the address, not in
> the 'real name' position on the left.)
On Fri, Aug 24, 2012 at 08:50:47PM -0700, Paul E. McKenney wrote:
> On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
> > On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
> > > On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
> > > > Hi,
> > > >
> > > > Changes since v1:
> > > >
> > > > - Fixed preempt handling in alpha idle loop
> > > > - added ack from Geert
> > > > - fixed stable email address, sorry :-/
> > > >
> > > > This time I built tested everywhere but: h8300 (compiler internal error),
> > > > and mn10300, parisc, score (cross compilers not available in
> > > > ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
> > > >
> > > > For testing, you can pull from:
> > > >
> > > > git://github.com/fweisbec/linux-dynticks.git
> > > > rcu/idle-fix-v2
> > > >
> > > > Thanks.
> > >
> > > I have queued these on -rcu branch rcu/idle:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> > >
> > > This problem has been in place since 3.3, so it is hard to argue that
> > > it is a regression for this merge window. I have therefore queued it
> > > for 3.7.
> >
> > I don't follow that; I would expect any serious bug fix (serious enough
> > for a stable update) to be acceptable for 3.6 at this point.
>
> OK, if any of the arch maintainers wishes to submit the patch to 3.6,
> they are free to do so -- just let me know and I will drop the patch from
> my tree.
>
> That said, all this does is cause spurious warnings to be printed, so
> not sure it really qualifies as serious. But I am happy to leave that
> decision with the individual arch maintainers -- it is their arch,
> after all, so their decision.
Couldn't that cause hung tasks due to long lasting synchronize_rcu() ?
On Sat, Aug 25, 2012 at 03:16:49PM +0200, Frederic Weisbecker wrote:
> On Fri, Aug 24, 2012 at 08:50:47PM -0700, Paul E. McKenney wrote:
> > On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
> > > On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
> > > > On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
> > > > > Hi,
> > > > >
> > > > > Changes since v1:
> > > > >
> > > > > - Fixed preempt handling in alpha idle loop
> > > > > - added ack from Geert
> > > > > - fixed stable email address, sorry :-/
> > > > >
> > > > > This time I built tested everywhere but: h8300 (compiler internal error),
> > > > > and mn10300, parisc, score (cross compilers not available in
> > > > > ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
> > > > >
> > > > > For testing, you can pull from:
> > > > >
> > > > > git://github.com/fweisbec/linux-dynticks.git
> > > > > rcu/idle-fix-v2
> > > > >
> > > > > Thanks.
> > > >
> > > > I have queued these on -rcu branch rcu/idle:
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> > > >
> > > > This problem has been in place since 3.3, so it is hard to argue that
> > > > it is a regression for this merge window. I have therefore queued it
> > > > for 3.7.
> > >
> > > I don't follow that; I would expect any serious bug fix (serious enough
> > > for a stable update) to be acceptable for 3.6 at this point.
> >
> > OK, if any of the arch maintainers wishes to submit the patch to 3.6,
> > they are free to do so -- just let me know and I will drop the patch from
> > my tree.
> >
> > That said, all this does is cause spurious warnings to be printed, so
> > not sure it really qualifies as serious. But I am happy to leave that
> > decision with the individual arch maintainers -- it is their arch,
> > after all, so their decision.
>
> Couldn't that cause hung tasks due to long lasting synchronize_rcu() ?
In theory, definitely. In practice, they haven't been running into it,
or they would be reporting hangs.
Thanx, Paul
On 26/08/12 04:18, Paul E. McKenney wrote:
> On Sat, Aug 25, 2012 at 03:16:49PM +0200, Frederic Weisbecker wrote:
>> On Fri, Aug 24, 2012 at 08:50:47PM -0700, Paul E. McKenney wrote:
>>> On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
>>>> On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
>>>>> On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Changes since v1:
>>>>>>
>>>>>> - Fixed preempt handling in alpha idle loop
>>>>>> - added ack from Geert
>>>>>> - fixed stable email address, sorry :-/
>>>>>>
>>>>>> This time I built tested everywhere but: h8300 (compiler internal error),
>>>>>> and mn10300, parisc, score (cross compilers not available in
>>>>>> ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
>>>>>>
>>>>>> For testing, you can pull from:
>>>>>>
>>>>>> git://github.com/fweisbec/linux-dynticks.git
>>>>>> rcu/idle-fix-v2
>>>>>>
>>>>>> Thanks.
>>>>>
>>>>> I have queued these on -rcu branch rcu/idle:
>>>>>
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>>>>>
>>>>> This problem has been in place since 3.3, so it is hard to argue that
>>>>> it is a regression for this merge window. I have therefore queued it
>>>>> for 3.7.
>>>>
>>>> I don't follow that; I would expect any serious bug fix (serious enough
>>>> for a stable update) to be acceptable for 3.6 at this point.
>>>
>>> OK, if any of the arch maintainers wishes to submit the patch to 3.6,
>>> they are free to do so -- just let me know and I will drop the patch from
>>> my tree.
>>>
>>> That said, all this does is cause spurious warnings to be printed, so
>>> not sure it really qualifies as serious. But I am happy to leave that
>>> decision with the individual arch maintainers -- it is their arch,
>>> after all, so their decision.
>>
>> Couldn't that cause hung tasks due to long lasting synchronize_rcu() ?
>
> In theory, definitely. In practice, they haven't been running into it,
> or they would be reporting hangs.
I am hereby reporting that RCU CPU stall warnings and hung tasks are
being experienced on SMP kernels built for generic Alpha. This problem
dates back quite a few kernel releases. The discussed patches appear to
fix the problem.
A backport to the 3.2 kernel, of at least the Alpha patches, would be
very much appreciated! :-)
Cheers
Michael.
On Sun, Aug 26, 2012 at 09:15:27AM +1200, Michael Cree wrote:
> On 26/08/12 04:18, Paul E. McKenney wrote:
> > On Sat, Aug 25, 2012 at 03:16:49PM +0200, Frederic Weisbecker wrote:
> >> On Fri, Aug 24, 2012 at 08:50:47PM -0700, Paul E. McKenney wrote:
> >>> On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
> >>>> On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
> >>>>> On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Changes since v1:
> >>>>>>
> >>>>>> - Fixed preempt handling in alpha idle loop
> >>>>>> - added ack from Geert
> >>>>>> - fixed stable email address, sorry :-/
> >>>>>>
> >>>>>> This time I built tested everywhere but: h8300 (compiler internal error),
> >>>>>> and mn10300, parisc, score (cross compilers not available in
> >>>>>> ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
> >>>>>>
> >>>>>> For testing, you can pull from:
> >>>>>>
> >>>>>> git://github.com/fweisbec/linux-dynticks.git
> >>>>>> rcu/idle-fix-v2
> >>>>>>
> >>>>>> Thanks.
> >>>>>
> >>>>> I have queued these on -rcu branch rcu/idle:
> >>>>>
> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> >>>>>
> >>>>> This problem has been in place since 3.3, so it is hard to argue that
> >>>>> it is a regression for this merge window. I have therefore queued it
> >>>>> for 3.7.
> >>>>
> >>>> I don't follow that; I would expect any serious bug fix (serious enough
> >>>> for a stable update) to be acceptable for 3.6 at this point.
> >>>
> >>> OK, if any of the arch maintainers wishes to submit the patch to 3.6,
> >>> they are free to do so -- just let me know and I will drop the patch from
> >>> my tree.
> >>>
> >>> That said, all this does is cause spurious warnings to be printed, so
> >>> not sure it really qualifies as serious. But I am happy to leave that
> >>> decision with the individual arch maintainers -- it is their arch,
> >>> after all, so their decision.
> >>
> >> Couldn't that cause hung tasks due to long lasting synchronize_rcu() ?
> >
> > In theory, definitely. In practice, they haven't been running into it,
> > or they would be reporting hangs.
>
> I am hereby reporting that RCU CPU stall warnings and hung tasks are
> being experienced on SMP kernels built for generic Alpha. This problem
> dates back quite a few kernel releases. The discussed patches appear to
> fix the problem.
OK, fair enough.
> A backport to the 3.2 kernel, of at least the Alpha patches, would be
> very much appreciated! :-)
Both Alpha patches should apply as-is back to 3.3, and should also fix
the problem. Could you please check this on the versions of interest?
If you are seeing something like this on 3.2 or earlier, you have some
other problem that needs to be tracked down separately.
Thanx, Paul
Hi!
On Sat, 25 Aug 2012, Paul E. McKenney wrote:
> Both Alpha patches should apply as-is back to 3.3, and should also fix
> the problem. Could you please check this on the versions of interest?
I just now tried them on top of 3.3.8 from linux-stable.git.
While they apply cleanly, I get a compile failure:
CC arch/alpha/kernel/process.o
arch/alpha/kernel/process.c: In function 'cpu_idle':
arch/alpha/kernel/process.c:64: error: implicit declaration of function 'schedule_preempt_disabled'
make[1]: *** [arch/alpha/kernel/process.o] Error 1
make: *** [arch/alpha/kernel] Error 2
AFAICT, schedule_preempt_disabled() was only introduced in 3.4
and thus needs to be backported for 3.3.
Regards,
Tobias
--
panic("%s: CORRUPTED BTREE OR SOMETHING", __FUNCTION__);
linux-2.6.6/fs/xfs/xfs_bmap.c