* [PATCH] stop_machine() vs. synchronous IPI send deadlock
@ 2005-11-09 11:16 Kirill Korotaev
2005-11-09 17:42 ` Kirill Korotaev
0 siblings, 1 reply; 2+ messages in thread
From: Kirill Korotaev @ 2005-11-09 11:16 UTC (permalink / raw)
To: linux-kernel, Linus Torvalds, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
Hello Andrew,
This patch fixes deadlock of stop_machine() vs. synchronous IPI send.
The problem is that stop_machine() disables interrupts before disabling
preemption on other CPUs. So if another CPU is preempted and then calls
something like flush_tlb_all() it will deadlock with CPU doing
stop_machine() and which can't process IPI due to disabled IRQs.
I changed stop_machine() to do the same things exactly as it does on
other CPUs, i.e. it should disable preemption first on _all_ CPUs
including itself and only after that disable IRQs.
Signed-Off-By: Kirill Korotaev <dev@sw.ru>
Kirill
[-- Attachment #2: diff-stopmachine --]
[-- Type: text/plain, Size: 542 bytes --]
--- ./kernel/stop_machine.c.stpmach 2005-11-01 12:06:03.000000000 +0300
+++ ./kernel/stop_machine.c 2005-11-09 13:58:03.000000000 +0300
@@ -114,13 +114,12 @@ static int stop_machine(void)
return ret;
}
- /* Don't schedule us away at this point, please. */
- local_irq_disable();
-
/* Now they are all started, make them hold the CPUs, ready. */
+ preempt_disable();
stopmachine_set_state(STOPMACHINE_PREPARE);
/* Make them disable irqs. */
+ local_irq_disable();
stopmachine_set_state(STOPMACHINE_DISABLE_IRQ);
return 0;
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] stop_machine() vs. synchronous IPI send deadlock
2005-11-09 11:16 [PATCH] stop_machine() vs. synchronous IPI send deadlock Kirill Korotaev
@ 2005-11-09 17:42 ` Kirill Korotaev
0 siblings, 0 replies; 2+ messages in thread
From: Kirill Korotaev @ 2005-11-09 17:42 UTC (permalink / raw)
To: Andrey Savochkin; +Cc: linux-kernel, Linus Torvalds, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
Sorry, hunk with corresponding preempt_enable was lost, sending patch again.
This patch fixes deadlock of stop_machine() vs. synchronous IPI send.
The problem is that stop_machine() disables interrupts before disabling
preemption on other CPUs. So if another CPU is preempted and then calls
something like flush_tlb_all() it will deadlock with CPU doing
stop_machine() and which can't process IPI due to disabled IRQs.
I changed stop_machine() to do the same things exactly as it does on
other CPUs, i.e. it should disable preemption first on _all_ CPUs
including itself and only after that disable IRQs.
Signed-Off-By: Kirill Korotaev <dev@sw.ru>
Kirill
[-- Attachment #2: diff-ms-stopmachine-ipi-deadlock-2 --]
[-- Type: text/plain, Size: 726 bytes --]
--- ./kernel/stop_machine.c.stpmach 2005-11-01 12:06:03.000000000 +0300
+++ ./kernel/stop_machine.c 2005-11-09 20:38:23.000000000 +0300
@@ -114,13 +114,12 @@ static int stop_machine(void)
return ret;
}
- /* Don't schedule us away at this point, please. */
- local_irq_disable();
-
/* Now they are all started, make them hold the CPUs, ready. */
+ preempt_disable();
stopmachine_set_state(STOPMACHINE_PREPARE);
/* Make them disable irqs. */
+ local_irq_disable();
stopmachine_set_state(STOPMACHINE_DISABLE_IRQ);
return 0;
@@ -130,6 +129,7 @@ static void restart_machine(void)
{
stopmachine_set_state(STOPMACHINE_EXIT);
local_irq_enable();
+ preempt_enable_no_resched();
}
struct stop_machine_data
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-11-09 17:32 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-09 11:16 [PATCH] stop_machine() vs. synchronous IPI send deadlock Kirill Korotaev
2005-11-09 17:42 ` Kirill Korotaev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox