[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091118171524.4d2f8cec@lxorguk.ukuu.org.uk>
Date: Wed, 18 Nov 2009 17:15:24 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Jan Blunck <jblunck@...e.de>
Cc: 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>,
Jan Blunck <jblunck@...e.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()
> Using the BKL in llseek() does not protect the inode's i_size from
> modification since the i_size is protected by a seqlock nowadays. Since
> default_llseek() is already using the i_size_read() wrapper it is not the
> BKL which is serializing the access here.
> The access to file->f_pos is not protected by the BKL either since its
> access in vfs_write()/vfs_read() is not protected by any lock. If the BKL
> is not protecting anything here it can clearly get removed.
No. Your logic is flawed
The BKL is protected something here - it protects the change of offset
with respect to other BKL users within drivers. The question is what if
anything in any other driver code depends upon the BKL and uses it to
protect f_pos. Probably very little if anything but a grep for f_pos
through the drivers might not be a bad idea before assuming this. Very
few touch f_pos except in their own llseek method.
--
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