Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761372AbZJMVsE (ORCPT ); Tue, 13 Oct 2009 17:48:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757588AbZJMVsE (ORCPT ); Tue, 13 Oct 2009 17:48:04 -0400 Received: from adsl-70-250-156-241.dsl.austtx.swbell.net ([70.250.156.241]:43450 "EHLO gw.microgate.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757520AbZJMVsD (ORCPT ); Tue, 13 Oct 2009 17:48:03 -0400 Message-ID: <4AD4F548.2030506@microgate.com> Date: Tue, 13 Oct 2009 16:46:48 -0500 From: Paul Fulghum User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Linus Torvalds CC: Boyan , =?ISO-8859-1?Q?=22Fr=E9d=E9ric_L=2E?= =?ISO-8859-1?Q?_W=2E_Meunier=22?= , "Justin P. Mattock" , Nix , Alan Cox , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Dmitry Torokhov , Ed Tomlinson , OGAWA Hirofumi Subject: Re: [Bug #14388] keyboard under X with 2.6.31 References: <56acieJJ2fF.A.nEB.Hzl0KB@chimera> <87ljjgfcbu.fsf@spindle.srvr.nix> <4AD3F769.5080405@gmail.com> <4AD437F9.9020708@yahoo.co.uk> <4AD4DE4C.4010402@yahoo.co.uk> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1595 Lines: 56 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/