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
| ||
|
Date: Sat, 16 Jun 2012 20:05:27 +0200 From: Pavel Machek <pavel@....cz> To: Kasza Péter <mr.schyte@...il.com>, "Rafael J. Wysocki" <rjw@...k.pl>, kernel list <linux-kernel@...r.kernel.org> Cc: gregkh@...uxfoundation.org Subject: Re: Deadlock in suspend console switch Hi! [Rafael really should have been notified]. Pavel On Sat 2012-06-16 17:36:24, Kasza Péter wrote: > Dear Recipients! > > I've found a deadlock bug in the suspend code. If the virtual terminal > is locked using the VT_PROCESS method (using perhaps vlock[1]), the > kernel cannot switch to the suspend console, so it waits indefinately > for the change to occur. > > The console change is initated from "pm_prepare_console" > (power/console.c), and the "vt_move_to_console" (tty/vt/vt_ioctl) call > hangs by calling the vt_waitactive function. (This problem obviously > doesn't occur if the disable_vt_switch variable is true) > > I haven't written a patch, because I'm not sure about the semantics we > should follow. > > Should the kernel perform the switch to the suspend console even if the > terminal is locked? Or should we block and notify the clients waiting > that the switch cannot be completed (the kernel currently just ignores > the request in this case)? > > The first option is easier to implement, because we don't have to notify > the clients about the error. However the second option is more > favourable, because userspace programs can fall into the trap, creating > a race condition between the switch and the call to the > VT_WAITACTIVE ioctl. > > In my opinion the suspend vt-switch should always succeed, and the > clients waiting on the switch should also be notified somehow. But this > requires some modification of the event handling code, and I haven't > found an elegant way to do that yet. > > [1] http://freecode.com/projects/vlock > -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
Powered by blists - more mailing lists