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]

Message-ID: <4AD4F548.2030506@microgate.com>
Date:	Tue, 13 Oct 2009 16:46:48 -0500
From:	Paul Fulghum <paulkf@...rogate.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Boyan <btanastasov@...oo.co.uk>,
	"Frédéric L. W. Meunier" <fredlwm@...il.com>,
	"Justin P. Mattock" <justinmattock@...il.com>,
	Nix <nix@...eri.org.uk>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Ed Tomlinson <edt@....ca>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Subject: Re: [Bug #14388] keyboard under X with 2.6.31

Linus Torvalds wrote:

> and by releasing that lock it actually seems to break all the buffering 
> guarantees! What can happen is:
> 
> 	CPU1 (or thread1 with PREEMPTION)
> 					CPU2 (or thread2 with PREEMPTION)
> 
> 	flush_to_ldisc()
> 	...
> 	spin_lock_irqsave(..)
> 	.. get one buffer..
> 	spin_unlock_irqrestore(..);
> 
> 			<- PREEMPTION POINT, anything can happen ->
> 			<- more buffers can be added, etc ->
> 
> 					flush_to_ldisc()
> 					spin_lock_irqsave(..)
> 					.. get second buffer..
> 					spin_unlock_irqrestore(..);
> 					->receive_buf(tty, char_buf, ...
> 					spin_lock_irqrestore(..)
> 					.. all done ..
> 
> 
> 	->receive_buf(tty, char_buf, ...
>         spin_lock_irqrestore(...)
> 
> Notice how the "->receive_buf()" calls were done out of order, even if the 
> data was perfectly in-order in the buffers.

The buffer head is removed and set to null just before
the flushing loop.

If flush_to_ldisc() is reentered with the head set to null, nothing
is done. New buffers can be added where you say, but they are
added to the tail. So the order of flushed data is retained.

This existing mechanism essentially does the same thing as your patch.


-- 
Paul Fulghum
MicroGate Systems, Ltd.
=Customer Driven, by Design=
(800)444-1982
(512)345-7791 (Direct)
(512)343-9046 (Fax)
Central Time Zone (GMT -5h)
www.microgate.com
--
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/