linux-kernel - Re: v3.13-rc6+ regression (ARM board)

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: <52C5DB5B.9050604@linaro.org>
Date:	Thu, 02 Jan 2014 13:34:19 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Krzysztof Hałasa <khalasa@...p.pl>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>, Willy Tarreau <w@....eu>,
	lkml <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Stephen Boyd <sboyd@...eaurora.org>
Subject: Re: v3.13-rc6+ regression (ARM board)

On 01/02/2014 12:43 PM, Linus Torvalds wrote:
> On Thu, Jan 2, 2014 at 12:30 PM, John Stultz <john.stultz@...aro.org> wrote:
>> So something else may be at play. Even with Linus' patch I reproduced a
>> similar hang here.
>>
>> Still chasing it down, but it looks like a seqlock deadlock where we're
>> calling read while holding the lock.
> Hmm. Only with lockdep, right?

Yep.

> Does lockdep perhaps read the scheduler clock? Afaik, we have
> lockstat_clock(), which uses local_clock(), which in turn translates
> to sched_clock_cpu(smp_processor_id())..
>
> So if that code now tries to read the scheduler clock when
> update_sched_clock() is doing a update and has done a
> write_seqcount_begin()...

Sigh. Deadlock by deadlock detection code.

So yea, it looks like this is the case.. though I've not been able to
get a backtrace during the hang to totally validate it (I'm just using
qemu's info registers and looking at the pc and lr).


So I'm guessing we'll just have to disable the lockdep logic here, which
is a little sad, since I'm a little nervous about the generic
sched_clock's locking (ie: works ok for ARM, but its not NMI safe), and
having some better debugging tools there would be helpful.


Anyway, I'll send out a patch to disable the lockdep usage here shortly.

thanks
-john








--
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/