Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933861AbZJMKcf (ORCPT ); Tue, 13 Oct 2009 06:32:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759389AbZJMKce (ORCPT ); Tue, 13 Oct 2009 06:32:34 -0400 Received: from earthlight.etchedpixels.co.uk ([81.2.110.250]:36227 "EHLO www.etchedpixels.co.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755630AbZJMKce (ORCPT ); Tue, 13 Oct 2009 06:32:34 -0400 Date: Tue, 13 Oct 2009 11:32:32 +0100 From: Alan Cox To: Linus Torvalds Cc: Nix , Paul Fulghum , "Justin P. Mattock" , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Boyan , Dmitry Torokhov , Ed Tomlinson , "=?ISO-8859-14?B?RnLpZOlyaWM=?= L. W. Meunier" , OGAWA Hirofumi Subject: Re: [Bug #14388] keyboard under X with 2.6.31 Message-ID: <20091013113232.384b2432@lxorguk.ukuu.org.uk> In-Reply-To: References: <56acieJJ2fF.A.nEB.Hzl0KB@chimera> <87ljjgfcbu.fsf@spindle.srvr.nix> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.14.7; x86_64-redhat-linux-gnu) Mime-Version: 1.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: 1436 Lines: 31 > It does that "tty_buffer_request_room()" call and subsequent copying with > no locking at all - sure, the tty_buffer_request_room() function itself > locks the buffers, but then unlocks it when returning, so when we actually > do the memcpy() etc, we can race with anybody. The tty_buffer_request_room() is a hint to help better allocation. It's also only safe to run from the receiving path of the driver (which has always been assumed not to make two parallel calls to the function at once. There is a simple reason the locking is sufficient. If you can call the function from two places at once in your serial driver at the same you've scrambled the data order so you've already lost. So - not a bug - and the lock changes don't actually "fix" any behaviour either because the ordering must be imposed by the caller. > pointless: they then call tty_insert_flip_string(), which means that the > tty_buffer_request_room() call was totally redundant ] It's a performance tweak. With a 3G USB modem or similar device running at 20Mbits or more being able to generate one allocation per chunk received for DMA made a measurable performance difference on some platforms. Alan -- 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/