linux-kernel - uswsusp and plymouth don't play nice together

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>] [day] [month] [year] [list]
Message-ID: <1337583139.52527.YahooMailNeo@web161806.mail.bf1.yahoo.com>
Date:	Sun, 20 May 2012 23:52:19 -0700 (PDT)
From:	Mikko Vinni <mmvinni@...oo.com>
To:	"plymouth@...ts.freedesktop.org" <plymouth@...ts.freedesktop.org>,
	"linux-pm@...ts.linux-foundation.org" 
	<linux-pm@...ts.linux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Rabin Vincent <rabin@....in>
Subject: uswsusp and plymouth don't play nice together

Hi,

has any uswsusp[1] (aka suspend-utils) or plymouth[2] developer tested the
two together? It seems there is a hang during resume from s2disk, and the
resume can be continued by pressing ALT-SysRq-K or ALT-SysRq-E.

This is not hardware specific neither new. For example, there is a bug report
for Debian[3] opened in 2010 (don't get confused by the reference to the
blinking fb cursor bug). Personally, I have tested on Ubuntu 12.04 and
Arch Linux (stable and some rc kernel versions for some months now).
Easily reproduced also in a virtual machine, without graphical splash.

The hang does not occur if using the in-kernel hibernation, nor when
not starting plymouth before resume.

ALT-SysRq-T shows this backtrace for the 'plymouthd' and 'resume' processes:

[   51.853427] plymouthd       D 0000000000000000     0    55      1 0x00000004 
[   51.853427]  ffff88000da6fd18 0000000000000086 ffff88000da58000 ffff88000da6ffd8 
[   51.853427]  ffff88000da6ffd8 ffff88000da6ffd8 ffff88000da59000 ffff88000da58000 
[   51.853427]  0000000000000000 ffff88000da58490 ffff88000da6fc78 ffff88000d9bd500 
[   51.853427] Call Trace: 
[   51.853427]  [<ffffffff8107d879>] ? finish_task_switch+0x49/0xd0 
[   51.853427]  [<ffffffff8145daa1>] ? __schedule+0x431/0x900 
[   51.853427]  [<ffffffff8145e0af>] schedule+0x3f/0x60 
[   51.853427]  [<ffffffff8109b9b3>] __refrigerator+0x43/0xe0 
[   51.853427]  [<ffffffff810bdb72>] ? cgroup_freezing+0x32/0x40 
[   51.853427]  [<ffffffff8106499d>] get_signal_to_deliver+0x56d/0x600 
[   51.853427]  [<ffffffff8118687c>] ? destroy_inode+0x3c/0x70 
[   51.853427]  [<ffffffff81014278>] do_signal+0x68/0x750 
[   51.853427]  [<ffffffff811b04f1>] ? ep_poll+0x2a1/0x360 
[   51.853427]  [<ffffffff811b09ed>] ? sys_epoll_ctl+0xad/0x850 
[   51.853427]  [<ffffffff8116dfeb>] ? fput+0x16b/0x210 
[   51.853427]  [<ffffffff810149e5>] do_notify_resume+0x65/0x80 
[   51.853427]  [<ffffffff81460122>] int_signal+0x12/0x17
[   51.853427] resume          S ffff88000da593c8     0    57      1 0x00000000 
[   51.853427]  ffff88000da5fd48 0000000000000082 ffff88000da59000 ffff88000da5ffd8 
[   51.853427]  ffff88000da5ffd8 ffff88000da5ffd8 ffffffff8180d020 ffff88000da59000 
[   51.853427]  ffff88000da59000 ffff88000da5ffd8 ffff88000da5ffd8 ffff88000da5ffd8 
[   51.853427] Call Trace: 
[   51.853427]  [<ffffffff8108014c>] ? ttwu_do_wakeup+0x2c/0x120 
[   51.853427]  [<ffffffff8145eed8>] ? _raw_spin_unlock_irqrestore+0x38/0x50 
[   51.853427]  [<ffffffff8145e0af>] schedule+0x3f/0x60 
[   51.853427]  [<ffffffff812e20f7>] vt_event_wait+0xa7/0x130 
[   51.853427]  [<ffffffff81072570>] ? abort_exclusive_wait+0xb0/0xb0 
[   51.853427]  [<ffffffff812e225d>] vt_waitactive+0x2d/0x60 
[   51.853427]  [<ffffffff8145cc26>] ? mutex_lock+0x16/0x30 
[   51.853427]  [<ffffffff812e4886>] vt_move_to_console+0x56/0xc0 
[   51.853427]  [<ffffffff81094388>] pm_prepare_console+0x18/0x40 
[   51.853427]  [<ffffffff81095974>] hibernation_restore+0x14/0x130 
[   51.853427]  [<ffffffff8109afe8>] snapshot_ioctl+0x218/0x4a0 
[   51.853427]  [<ffffffff8117e787>] do_vfs_ioctl+0x97/0x530 
[   51.853427]  [<ffffffff8118ae14>] ? mntput+0x24/0x40 
[   51.853427]  [<ffffffff8116dfeb>] ? fput+0x16b/0x210 
[   51.853427]  [<ffffffff8117ecb9>] sys_ioctl+0x99/0xa0 
[   51.853427]  [<ffffffff8145fe69>] system_call_fastpath+0x16/0x1b 


Does plymouthd register to listen for console change, or something else
that it can't do while refrigerated?

There was on May 18th a patch proposed for the vt_event_wait() function[4],
but that patch has no effect for this particular hang.

Apparently Mandriva has a patch[5] to add plymouth support to uswsusp, but one
would assume that s2disk/resume should not hang in its default state.

Any ideas?


Mikko

--
[1] http://suspend.sourceforge.net/
[2] http://cgit.freedesktop.org/plymouth/
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593795
[4] "Race in vt_event_wait() during suspend/resume": http://article.gmane.org/gmane.linux.kernel/1299487
[5] changelog e.g.: http://rpmfind.net//linux/RPM/mandriva/2011/x86_64/media/main/release/suspend-0.8-12.20080612.x86_64.html
--
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/