* [PATCH 2/2] stop_machine: dequeue work before signal completion
@ 2013-02-08 3:42 Hillf Danton
2013-02-08 8:22 ` Namhyung Kim
2013-02-09 19:17 ` Tejun Heo
0 siblings, 2 replies; 6+ messages in thread
From: Hillf Danton @ 2013-02-08 3:42 UTC (permalink / raw)
To: Rusty Russell, Tejun Heo; +Cc: Andrew Morton, Ingo Molnar, Hillf Danton, LKML
As checked with BUG_ON in the case of CPU_UP_PREPARE, we have to dequeue
work first for further actions, then stopper reaches sane and clear state.
Signed-off-by: Hillf Danton <dhillf@gmail.com>
---
--- a/kernel/stop_machine.c Fri Feb 8 11:22:44 2013
+++ b/kernel/stop_machine.c Fri Feb 8 11:29:40 2013
@@ -342,8 +342,12 @@ static int __cpuinit cpu_stop_cpu_callba
kthread_stop(stopper->thread);
/* drain remaining works */
spin_lock_irq(&stopper->lock);
- list_for_each_entry(work, &stopper->works, list)
+ while (!list_empty(&stopper->works)) {
+ work = list_first_entry(&stopper->works,
+ struct cpu_stop_work, list);
+ list_del_init(&work->list);
cpu_stop_signal_done(work->done, false);
+ }
stopper->enabled = false;
spin_unlock_irq(&stopper->lock);
/* release the stopper */
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] stop_machine: dequeue work before signal completion
2013-02-08 3:42 [PATCH 2/2] stop_machine: dequeue work before signal completion Hillf Danton
@ 2013-02-08 8:22 ` Namhyung Kim
2013-02-08 12:03 ` Hillf Danton
2013-02-09 19:17 ` Tejun Heo
1 sibling, 1 reply; 6+ messages in thread
From: Namhyung Kim @ 2013-02-08 8:22 UTC (permalink / raw)
To: Hillf Danton; +Cc: Rusty Russell, Tejun Heo, Andrew Morton, Ingo Molnar, LKML
On Fri, 8 Feb 2013 11:42:43 +0800, Hillf Danton wrote:
> As checked with BUG_ON in the case of CPU_UP_PREPARE, we have to dequeue
> work first for further actions, then stopper reaches sane and clear state.
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Thanks,
Namhyung
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] stop_machine: dequeue work before signal completion
2013-02-08 8:22 ` Namhyung Kim
@ 2013-02-08 12:03 ` Hillf Danton
0 siblings, 0 replies; 6+ messages in thread
From: Hillf Danton @ 2013-02-08 12:03 UTC (permalink / raw)
To: Namhyung Kim; +Cc: Rusty Russell, Tejun Heo, Andrew Morton, Ingo Molnar, LKML
Hello Namhyung
On Fri, Feb 8, 2013 at 4:22 PM, Namhyung Kim <namhyung@kernel.org> wrote:
> On Fri, 8 Feb 2013 11:42:43 +0800, Hillf Danton wrote:
>> As checked with BUG_ON in the case of CPU_UP_PREPARE, we have to dequeue
>> work first for further actions, then stopper reaches sane and clear state.
>
> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
>
Double thanks since I did not add you in the cc list, may bad;(
Hillf
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] stop_machine: dequeue work before signal completion
2013-02-08 3:42 [PATCH 2/2] stop_machine: dequeue work before signal completion Hillf Danton
2013-02-08 8:22 ` Namhyung Kim
@ 2013-02-09 19:17 ` Tejun Heo
1 sibling, 0 replies; 6+ messages in thread
From: Tejun Heo @ 2013-02-09 19:17 UTC (permalink / raw)
To: Hillf Danton; +Cc: Rusty Russell, Andrew Morton, Ingo Molnar, LKML
Hello, again.
On Fri, Feb 08, 2013 at 11:42:43AM +0800, Hillf Danton wrote:
> As checked with BUG_ON in the case of CPU_UP_PREPARE, we have to dequeue
> work first for further actions, then stopper reaches sane and clear state.
When a CPU is finally put down in either CPU_UP_CANCELLED or
CPU_POST_DEAD, cpu_stop_cpu_callback() signals immediate completion on
all cpu_stop_works still queued on the dead CPU; unfortunately, this
code is buggy in that it doesn't remove the canceled work items off
the stopper->works leaving it corrupted, which will trigger BUG_ON()
during CPU_UP_PREPARE if the CPU is brought back online.
This bug isn't easily triggered because CPU_DOWN has to race against
cpu_stop calls and most, if not all, cpu stop users pin target CPUs.
Fix it by popping each work item off stopper->works.
> Signed-off-by: Hillf Danton <dhillf@gmail.com>
Maybe
Cc: stable@vger.kernel.org
> --- a/kernel/stop_machine.c Fri Feb 8 11:22:44 2013
> +++ b/kernel/stop_machine.c Fri Feb 8 11:29:40 2013
> @@ -342,8 +342,12 @@ static int __cpuinit cpu_stop_cpu_callba
> kthread_stop(stopper->thread);
> /* drain remaining works */
> spin_lock_irq(&stopper->lock);
> - list_for_each_entry(work, &stopper->works, list)
> + while (!list_empty(&stopper->works)) {
> + work = list_first_entry(&stopper->works,
> + struct cpu_stop_work, list);
> + list_del_init(&work->list);
> cpu_stop_signal_done(work->done, false);
> + }
I think your previous version was better with @work declaration moved
inside the while() loop.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] stop_machine: dequeue work before signal completion
2013-02-10 5:26 Hillf Danton
@ 2013-02-12 17:38 ` Tejun Heo
0 siblings, 0 replies; 6+ messages in thread
From: Tejun Heo @ 2013-02-12 17:38 UTC (permalink / raw)
To: Hillf Danton
Cc: Namhyung Kim, Rusty Russell, Andrew Morton, Ingo Molnar, LKML, Stable
On Sun, Feb 10, 2013 at 01:26:11PM +0800, Hillf Danton wrote:
> When a CPU is finally put down in either CPU_UP_CANCELLED or
> CPU_POST_DEAD, cpu_stop_cpu_callback() signals immediate completion on
> all cpu_stop_works still queued on the dead CPU; unfortunately, this
> code is buggy in that it doesn't remove the canceled work items off
> the stopper->works leaving it corrupted, which will trigger BUG_ON()
> during CPU_UP_PREPARE if the CPU is brought back online.
>
> This bug isn't easily triggered because CPU_DOWN has to race against
> cpu_stop calls and most, if not all, cpu stop users pin target CPUs.
>
> Fix it by popping each work item off stopper->works.
>
> Thanks Tejun for sharing commit message, again.
>
> Signed-off-by: Hillf Danton <dhillf@gmail.com>
> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
> Cc: stable@vger.kernel.org
Acked-by: Tejun Heo <tj@kernel.org>
Andrew, this one too.
Thank you!
--
tejun
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 2/2] stop_machine: dequeue work before signal completion
@ 2013-02-10 5:26 Hillf Danton
2013-02-12 17:38 ` Tejun Heo
0 siblings, 1 reply; 6+ messages in thread
From: Hillf Danton @ 2013-02-10 5:26 UTC (permalink / raw)
To: Tejun Heo
Cc: Namhyung Kim, Rusty Russell, Andrew Morton, Ingo Molnar, LKML,
Hillf Danton, Stable
When a CPU is finally put down in either CPU_UP_CANCELLED or
CPU_POST_DEAD, cpu_stop_cpu_callback() signals immediate completion on
all cpu_stop_works still queued on the dead CPU; unfortunately, this
code is buggy in that it doesn't remove the canceled work items off
the stopper->works leaving it corrupted, which will trigger BUG_ON()
during CPU_UP_PREPARE if the CPU is brought back online.
This bug isn't easily triggered because CPU_DOWN has to race against
cpu_stop calls and most, if not all, cpu stop users pin target CPUs.
Fix it by popping each work item off stopper->works.
Thanks Tejun for sharing commit message, again.
Signed-off-by: Hillf Danton <dhillf@gmail.com>
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Cc: stable@vger.kernel.org
---
--- a/kernel/stop_machine.c Sun Feb 10 13:00:00 2013
+++ b/kernel/stop_machine.c Sun Feb 10 13:02:18 2013
@@ -334,23 +334,24 @@ static int __cpuinit cpu_stop_cpu_callba
#ifdef CONFIG_HOTPLUG_CPU
case CPU_UP_CANCELED:
case CPU_POST_DEAD:
- {
- struct cpu_stop_work *work;
-
sched_set_stop_task(cpu, NULL);
/* kill the stopper */
kthread_stop(stopper->thread);
/* drain remaining works */
spin_lock_irq(&stopper->lock);
- list_for_each_entry(work, &stopper->works, list)
+ while (!list_empty(&stopper->works)) {
+ struct cpu_stop_work *work;
+ work = list_first_entry(&stopper->works,
+ struct cpu_stop_work, list);
+ list_del_init(&work->list);
cpu_stop_signal_done(work->done, false);
+ }
stopper->enabled = false;
spin_unlock_irq(&stopper->lock);
/* release the stopper */
put_task_struct(stopper->thread);
stopper->thread = NULL;
break;
- }
#endif
}
--
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-02-12 17:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-08 3:42 [PATCH 2/2] stop_machine: dequeue work before signal completion Hillf Danton
2013-02-08 8:22 ` Namhyung Kim
2013-02-08 12:03 ` Hillf Danton
2013-02-09 19:17 ` Tejun Heo
2013-02-10 5:26 Hillf Danton
2013-02-12 17:38 ` Tejun Heo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).