linux-kernel - Re: [-rc7 regression] Block IO/VFS/ext3/timer spinlock lockup?

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: <CA+55aFxrjsVkBwUdjmc4MYvEsjEyCJZ7AFpGrWvbbQFB3EVtHA@mail.gmail.com>
Date:	Wed, 13 Feb 2013 08:59:23 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alexander Viro <viro@....linux.org.uk>,
	"Theodore Ts'o" <tytso@....edu>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [-rc7 regression] Block IO/VFS/ext3/timer spinlock lockup?

On Wed, Feb 13, 2013 at 3:10 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
>
> Setting up Logical Volume Management: [   13.140000] BUG: spinlock lockup suspected on CPU#1, lvm.static/139
> [   13.140000] BUG: spinlock lockup suspected on CPU#1, lvm.static/139
> [   13.140000]  lock: 0x97fe9fc0, .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1
> [   13.140000] Pid: 139, comm: lvm.static Not tainted 3.8.0-rc7 #216702
> [   13.140000] Call Trace:
> [   13.140000]  [<792b5e66>] spin_dump+0x73/0x7d
> [   13.140000]  [<7916a347>] do_raw_spin_lock+0xb2/0xe8
> [   13.140000]  [<792b9412>] _raw_spin_lock_irqsave+0x35/0x3e
> [   13.140000]  [<790391e8>] prepare_to_wait+0x18/0x57

The wait-queue spinlock? That sounds *very* unlikely to deadlock due
to any bugs in block layer or filesystems. There are never any
downcalls to those from within that spinlock or any other locks taken
inside of it.

The waitqueue function would be the only thing that does anything
inside the lock, and very few things use that. In this case, it's the
bitwait stuff, so that function does get used, but it doesn't have any
locking except for when it then calls down to the standard
autoremove_wake_function -> default_wake_function -> try_to_wake_up.

So the *only* thing inside that wait-queue spinlock would seem to be
the scheduler (pi_lock in particular, and the "while (p->on_cpu)"
thing).

Of course, those kinds of locks are also something lockdep can't check, so...

> It turns out that in this particular case the randomized boot
> parameters appear to make a difference:
>
> CONFIG_CMDLINE="nmi_watchdog=0 nolapic_timer hpet=disable idle=poll highmem=512m acpi=off"

Is it repeatable enough with those flags that you could try removing
them one at a time and seeing if one or two of them don't matter?

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