From: Ingo Molnar <mingo@elte.hu>
To: Gautham R Shenoy <ego@in.ibm.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Dhaval Giani <dhaval@linux.vnet.ibm.com>,
Dipankar Sarma <dipankar@in.ibm.com>,
laijs@cn.fujitsu.com, Peter Zijlstra <a.p.zijlstra@chello.nl>,
lkml <linux-kernel@vger.kernel.org>,
Rusty Russel <rusty@rustcorp.com.au>
Subject: Re: [PATCH] fix rcu vs hotplug race
Date: Tue, 1 Jul 2008 08:16:01 +0200 [thread overview]
Message-ID: <20080701061600.GF14658@elte.hu> (raw)
In-Reply-To: <20080701053900.GB8205@in.ibm.com>
* Gautham R Shenoy <ego@in.ibm.com> wrote:
> So, it's the design of stop_machine() that's preventing someone from
> updating the cpu_online_map while force_quiescent_state() is
> performing the cpu_is_online() check. Becase we always call
> force_quiescent_state() with irqs disabled :)
Paul, do you concur? I'll apply the commit in the form below to
tip/core/urgent if Paul agrees.
Ingo
----------------------------------->
Subject: cpu-hotplug + rcu: fix spurious warning
From: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Date: Mon, 23 Jun 2008 16:07:00 +0530
On running kernel compiles in parallel with cpu hotplug,
------------[ cut here ]------------
WARNING: at arch/x86/kernel/smp.c:118
native_smp_send_reschedule+0x21/0x36()
Modules linked in:
Pid: 27483, comm: cc1 Not tainted 2.6.26-rc7 #1
[<c01217d9>] warn_on_slowpath+0x41/0x5d
[<c01515b7>] ? generic_file_aio_read+0x10f/0x137
[<c0151340>] ? file_read_actor+0x0/0xf7
[<c013ae4c>] ? validate_chain+0xaa/0x29c
[<c013c854>] ? __lock_acquire+0x612/0x666
[<c013c854>] ? __lock_acquire+0x612/0x666
[<c013ae4c>] ? validate_chain+0xaa/0x29c
[<c01715d3>] ? file_kill+0x2d/0x30
[<c013cbd7>] ? __lock_release+0x4b/0x51
[<c01715d3>] ? file_kill+0x2d/0x30
[<c0110355>] native_smp_send_reschedule+0x21/0x36
[<c014fe8f>] force_quiescent_state+0x47/0x57
[<c014fef0>] call_rcu+0x51/0x6d
[<c01713b3>] __fput+0x130/0x158
[<c0171231>] fput+0x17/0x19
[<c016fd99>] filp_close+0x4d/0x57
[<c016fdff>] sys_close+0x5c/0x97
[<c0103861>] sysenter_past_esp+0x6a/0xb1
=======================
---[ end trace aa35f3913ddf2d06 ]---
This is because a reschedule is sent to a CPU which is offline.
Just ensure that the CPU we send the smp_send_reschedule is actually
online.
It's the design of stop_machine() that's preventing someone from
updating the cpu_online_map while force_quiescent_state() is
performing the cpu_is_online() check. Becase we always call
force_quiescent_state() with irqs disabled :)
Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Acked-by: Gautham R Shenoy <ego@in.ibm.com>
Cc: paulmck@linux.vnet.ibm.com
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/rcuclassic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: tip/kernel/rcuclassic.c
===================================================================
--- tip.orig/kernel/rcuclassic.c
+++ tip/kernel/rcuclassic.c
@@ -93,7 +93,8 @@ static void force_quiescent_state(struct
cpumask = rcp->cpumask;
cpu_clear(rdp->cpu, cpumask);
for_each_cpu_mask(cpu, cpumask)
- smp_send_reschedule(cpu);
+ if (cpu_online(cpu))
+ smp_send_reschedule(cpu);
}
}
#else
next prev parent reply other threads:[~2008-07-01 6:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-23 10:37 [PATCH] fix rcu vs hotplug race Dhaval Giani
2008-06-23 10:58 ` Ingo Molnar
2008-06-23 11:49 ` Gautham R Shenoy
2008-06-24 11:01 ` Ingo Molnar
2008-06-26 15:27 ` Paul E. McKenney
2008-06-27 4:47 ` Gautham R Shenoy
2008-06-27 5:18 ` Dipankar Sarma
2008-06-27 5:49 ` Dhaval Giani
2008-06-27 14:58 ` Paul E. McKenney
2008-07-01 5:39 ` Gautham R Shenoy
2008-07-01 6:16 ` Ingo Molnar [this message]
2008-07-01 6:28 ` Dhaval Giani
2008-07-01 6:35 ` Ingo Molnar
2008-07-01 6:52 ` Ingo Molnar
2008-07-01 7:48 ` Ingo Molnar
2008-07-01 8:32 ` Ingo Molnar
2008-07-01 19:46 ` Paul E. McKenney
2008-08-01 21:01 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080701061600.GF14658@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=dhaval@linux.vnet.ibm.com \
--cc=dipankar@in.ibm.com \
--cc=ego@in.ibm.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.