linux-kernel - Re: Soft lockup during suspend since ~2.6.36

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]

Date:	Mon, 4 Apr 2011 16:40:15 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Thilo-Alexander Ginkel" <thilo@...kel.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Soft lockup during suspend since ~2.6.36

On Monday 04 April 2011, Thilo-Alexander Ginkel wrote:
> On Mon, Apr 4, 2011 at 05:02, Arnd Bergmann <arnd@...db.de> wrote:

> Unfortunately, the output via a serial console becomes garbled after
> "Entering mem sleep", so I went for patching dumpstack_64.c and a
> couple of other source files to reduce the verbosity. I hope not to
> have stripped any essential information. The result is available in
> these pictures:
>   https://secure.tgbyte.de/dropbox/IeZalo4t-1.jpg
>   https://secure.tgbyte.de/dropbox/IeZalo4t-2.jpg
> 
> For both traces, the printed error message reads: "BUG: soft lockup -
> CPU#3 stuck for 67s! [kblockd:28]"
> 
> (After a bit of Googling I understand that a soft lockup is probably
> different from a deadlock - please correct me if that assumption is
> wrong)

My interpretation is that some process tries to use
kblockd_schedule_work() after the CPU for that workqueue has been
disabled. The work queue functions (worker_maybe_bind_and_lock)
is waiting for the CPU to become available, which it doesn't do.

You see different outputs every time the softlockup detection finds
this because the loop is in different states here. The reason why
the spin_unlock shows up here is because that is when the interrupts
get enabled and the softlockup detection notices the timeout.

I'm pretty sure that this has nothing to do with the bisected bug
that you initially found, but maybe somebody else can try analysing
this better.

> > Yet another idea would be to set /sys/kernel/printk_delay so that the
> > oops gets printed slower.
> 
> Hm, that file does not exist on my machine. Does it need a special
> compile-time config  option to be enabled?

Sorry, I meant /proc/sys/kernel/printk_delay.

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