Messages in this thread | | | Date | Thu, 26 May 2011 17:45:08 +0200 | From | Oleg Nesterov <> | Subject | Re: [BUG] "sched: Remove rq->lock from the first half of ttwu()" locks up on ARM |
| |
On 05/26, Peter Zijlstra wrote: > > static void ttwu_queue(struct task_struct *p, int cpu) > { > @@ -2631,17 +2650,17 @@ try_to_wake_up(struct task_struct *p, un > while (p->on_cpu) { > #ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW > /* > - * If called from interrupt context we could have landed in the > - * middle of schedule(), in this case we should take care not > - * to spin on ->on_cpu if p is current, since that would > - * deadlock. > + * In case the architecture enables interrupts in > + * context_switch(), we cannot busy wait, since that > + * would lead to live-locks when an interrupt hits and > + * tries to wake up @prev. So bail and do a complete > + * remote wakeup. > */ > - if (p == current) { > - ttwu_queue(p, cpu); > + if (ttwu_activate_remote(p, wake_flags))
Stupid question. Can't we fix this problem if we do
- if (p == current) + if (cpu == raw_smp_processor_id())
?
I forgot the rules... but iirc task_cpu(p) can't be changed under us?
Oleg.
| |