linux-kernel - Re: [Bug #14388] keyboard under X with 2.6.31

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

Date:	Mon, 12 Oct 2009 17:16:29 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Nix <nix@...eri.org.uk>
cc:	"Justin P. Mattock" <justinmattock@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Boyan <btanastasov@...oo.co.uk>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Ed Tomlinson <edt@....ca>,
	Frédéric L. W. Meunier 
	<fredlwm@...il.com>, OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Subject: Re: [Bug #14388] keyboard under X with 2.6.31

On Mon, 12 Oct 2009, Nix wrote:
> On 12 Oct 2009, Justin P. Mattock uttered the following:
> 
> > Not sure where this stands. Right now all three machines I have seem  to be having no issues with the kayboard
> > (xserver 1.6.*) I can go and build the latest xserver(1.7) to see if I  hit something.
> [...]
> >> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=14388
> >> Subject        : keyboard under X with 2.6.31
> >> Submitter    : Frédéric L. W. Meunier <fredlwm@...il.com>
> >> Date        : 2009-10-07 20:19 (5 days old)
> >> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e043e42bdb66885b3ac10d27a01ccb9972e2b0a3
> >> References    : http://marc.info/?l=linux-kernel&m=125494753228217&w=4
> 
> I have been seeing problems precisely like those described (sometimes
> the keyboard dies, sometimes it gets 'stuck' with a key held down, until
> I switch TTYs, which generally means killing X as I'm not aware of an
> easy way to switch VTs using only the mouse), since I moved to 2.6.31

The particular commit that was bisected to should really not matter for X, 
except perhaps from a timing standpoint.

The problem it fixed was in pty's, and X doesn't use them much if at all 
(various X _programs_ may, of course, but the symptoms don't sound like 
it's just a particular X app that has issues, but more of a generic X 
keyboard handling thing)

But for non-pty's, there should be no semantic changes from that commit 
outside of some general tty timing differences by doing that 
tty_flush_to_ldisc() at new points.

I could fairly easily imagine that some timing difference does expose 
another longer-standing problem in either the kernel or X itself. So the 
bisection isn't necessarily wrong, it's just not likely telling us what 
the real problem is.

Of course, maybe there is some race condition in the tty_buffer.c code. We 
_used_ to not call flush_to_ldisc() except through the workqueue code, so 
races would not be seen in normal circumstances. Now that flush_to_ldisc() 
could easily get called both synchronously from tty_read()/tty_poll(), 
while also being hit from the workqueues.

Alan, Ogawa-san, do either of you see some problem in tty_buffer.c, 
perhaps?

		Linus

--
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/