linux-kernel - Re: Deadlock in suspend console switch

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: <20120616180526.GB29917@elf.ucw.cz>
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/