Re: [BUG] lockup with the latest kernel

[Tejun Heo <tj@kernel.org>]

Hello,

Ingo Molnar wrote:
>> Eh... don't have earlier AMD doc and gotta go now.  Can somebody 
>> please check?  But it looks like we can deadlock by simply sending 
>> RESCHEDULE_VECTOR more than two times while holding rq lock on 
>> AMD?
> 
> We poll ICR in the send-IPI logic before sending it out - so this 
> shouldnt happen. The restrictions above should at most cause extra 
> polling latency (i.e. it's a performance detail, not a lockup 
> source). See all the *wait_icr_idle() methods in the IPI sending 
> logic in arch/x86.

Ah... good.  I'm not all that familiar with the area so I was kind of
shooting in the dark.

> Neither TLB flushes nor reschedule IPIs are idempotent, so if this 
> was broken and if we lost requested events on remote CPUs we'd 
> notice it rather quickly via TLB flush related hangs or scheduling 
> latencies or lost wakeups, on a rather large category of CPUs.

But it still looks like we can quite easily fall into deadlock when
there are multiple cpus.  cpu0 holding rq_lock and sends RESCHEUDLE,
cpu1 waiting on rq_lock with irq disabled and some other cpus already
sent three other IPIs to cpu1 then cpu0 will lock up on the BUSY bit
when it tries to send RESCHEDULE, no?

> I think Linus's suggestion that it's the zero mask quirk on certain 
> older CPUs that is causing problems on that system should be 
> examined ... does .31-rc8 work fine?

Yeap, it would be great if that's the case.

Thanks.

-- 
tejun