[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.01.0910130755360.3438@localhost.localdomain>
Date: Tue, 13 Oct 2009 08:02:35 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
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
On Tue, 13 Oct 2009, Linus Torvalds wrote:
>
> - whoever is _reading_ the buffer, and due to memory ordering may see the
> update to the buffer length _before_ it actually sees the data itself.
> That spinlock does all the memory ordering too.
Hmm. This one looks like it's ok, because whenever we commit it, we do
take the spinlock, so '->commit' is protected for the reader side.
> - scrambling the data order with two writers is certainly less annoying
> than potentially screwing up ->used entirely, and having the memcpy's
> overflow the buffer. Both writers may have decided that there is enough
> room for each one - but that does not mean that there is enough room
> for _both_.
.. but this one is still true. Anybody who doesn't lock writers at a
higher level could easily end up causing some really subtle memory
corruption.
But maybe all users really are safe.
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/
Powered by blists - more mailing lists