[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091118175517.174ec906@lxorguk.ukuu.org.uk>
Date: Wed, 18 Nov 2009 17:55:17 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Oliver Neukum <oliver@...kum.org>
Cc: Jamie Lokier <jamie@...reable.org>, Jan Blunck <jblunck@...e.de>,
linux-fsdevel@...r.kernel.org,
"Linux-Kernel Mailinglist" <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>, jkacur@...hat.com,
Thomas Gleixner <tglx@...utronix.de>,
Arnd Bergmann <arnd@...db.de>,
Christoph Hellwig <hch@...radead.org>,
Frédéric Weisbecker <fweisbec@...il.com>,
Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH 1/2] BKL: Remove BKL from default_llseek()
> > Of course, drivers shouldn't be using f_pos outside their llseek
> > method, as they should all behave the same with pread/pwrite as with
> > llseek+read/write.
>
> Might not a driver update f_pos after read/write?
The driver updates the passed pointer to an offset. It has no idea how to
lock that and that is isolated and handled higher up the stack.
There are no obvious reasons to peer at f_pos. I've so far checked all of
drivers/char and that is clean (as well as being the most likely suspect
for old code). A sweep of the other driver subsystems should be
enough to find any offenders
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