linux-kernel - Re: consolechars switches tty since 8b92e87 vt: add an event interface

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] [day] [month] [year] [list]

Date:	Sun, 15 Nov 2009 20:18:55 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Przemysław Pawełczyk 
	<przemyslaw@...elczyk.it>
Cc:	Alan Cox <alan@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: consolechars switches tty since 8b92e87 vt: add an event 
 interface

> ioctl(3, VIDIOC_G_COMP or VT_ACTIVATE, 0x2) = 0

Switch to VT 2
> ioctl(3, VIDIOC_S_COMP or VT_WAITACTIVE, 0x2) = 0

Wait for VT 2 to activate

> ioctl(3, PIO_UNIMAPCLR, 0x7fff042a0160) = 0
> ioctl(3, PIO_UNIMAP, 0x7fff042a0730)    = 0

Set maps

> ioctl(3, VIDIOC_G_COMP or VT_ACTIVATE, 0x1) = 0

Switch back to VT 1

> ioctl(3, VIDIOC_S_COMP or VT_WAITACTIVE, 0x1) = 0

Wait for VT1 to activate.

Nothing odd there, definitely looks like a kernel problem.

> I have one thing to add. It looks like that is not fully deterministic
> behavior, at least not at f278a2f^ I'm using now. Occasionally tty
> isn't switched. I wasn't aware of this before.

The console switch is asynchronously handled so a race or a bug in the
handling of the event wait which is what I suspect would indeed show up
that behaviour. X and other apps don't do sudden fast switch and switch
backs which would hide such a bug.
 
> I just booted that f278a2f^ (i.e. 569ec4c) while consolechars were
> limited only to console-setup script, but this time tty1 remained on
> the screen and I didn't get "INIT: open(/dev/console): Input/output
> error" I was seeing before. I'm not sure whether it is relevant here.

The I/O error is a different bug (technically a user space one), but the
new behaviour was different, not at all expected and was fixed back to
the old sane behaviour.
--
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/