Messages in this thread | | | Date | Sat, 16 Jun 2012 20:05:27 +0200 | From | Pavel Machek <> | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |