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: <20091013113232.384b2432@lxorguk.ukuu.org.uk>
Date:	Tue, 13 Oct 2009 11:32:32 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Nix <nix@...eri.org.uk>, Paul Fulghum <paulkf@...rogate.com>,
	"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

> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ