linux-kernel - Re: [BUG] lockup with the latest kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A978052.6000908@kernel.org>
Date:	Fri, 28 Aug 2009 15:59:30 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [BUG] lockup with the latest kernel

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/