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:	Sun, 3 Apr 2011 23:08:51 +0200
From:	Thilo-Alexander Ginkel <thilo@...kel.com>
To:	linux-kernel@...r.kernel.org
Cc:	Arnd Bergmann <arnd@...db.de>
Subject: Re: Soft lockup during suspend since ~2.6.36

On Sun, Apr 3, 2011 at 19:32, Thilo-Alexander Ginkel <thilo@...kel.com> wrote:
> A good night of sleep and some Googling later I am under the
> impression that this issue was already supposedly fixed by the
> following commit a long time ago:
>  http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=commitdiff;h=9c9e54a8df0be48aa359744f412377cc55c3b7d2
>  http://permalink.gmane.org/gmane.linux.kernel/1024386
>
> This makes some sense as versions closer to 2.6.36 only lock up
> sporadically whereas the original bug locks up reliably. I'll try to
> get a backtrace for the sporadic bug, but may only be able to do so
> using a tainted kernel as my text console does not survive
> suspend/resume without proprietary drivers (and the serial console
> also breaks during the relevant suspend phase). I hope, this is
> acceptable.

All right. I have actually been able to obtain a backtrace for a
2.6.36 kernel, which only shows this problem sporadically (so this
probably has a different root cause).

It all starts with the suspend sequence hanging while shutting down
non-boot CPUs (the CPU# varies from case to case):
  https://secure.tgbyte.de/dropbox/ueph3Ohm-1.jpg

Then, after some time, the following backtrace is written:
  https://secure.tgbyte.de/dropbox/ueph3Ohm-2.jpg

Transcript:
| RIP: _raw_spin_unlock_irqrestore
| Call Stack:
|   _set_cpus_allowed_ptr
|   worker_maybe_bind_and_lock
|   rescuer_thread
|   rescuer_thread
|   kernel_thread_helper
|   kthread
|   kernel_thread_helper
|   kthread

After some more time, the following backtrace is printed:
  https://secure.tgbyte.de/dropbox/ueph3Ohm-3.jpg

Transcript:
| RIP: worker_maybe_bind_and_lock
| Call Stack:
|   rescuer_thread
|   rescuer_thread
|   kernel_thread_helper
|   kthread
|   kernel_thread_helper
|   kthread

>From then on these two backtraces are printed in an alternating fashion.

Unfortunately, the top of the output is missing as it does not fit on
screen (does someone know an even smaller console font?), but I assume
it's the deadlock detection.

Thanks,
Thilo
--
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/