From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: [PATCH v2] Do a proper locking for mmap and block size change Date: Thu, 29 Nov 2012 14:15:03 -0500 Message-ID: <20121129191503.GB3490@shiny> References: <50B4B313.3030707@kernel.dk> <50B5CC5A.8060607@kernel.dk> <20121128194314.GF4939@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Mikulas Patocka , Al Viro , Jens Axboe , Jeff Chua , Lai Jiangshan , Jan Kara , lkml , linux-fsdevel To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Nov 29, 2012 at 12:02:17PM -0700, Linus Torvalds wrote: > On Thu, Nov 29, 2012 at 9:19 AM, Linus Torvalds > wrote: > > > > I think I'll apply this for 3.7 (since it's too late to do anything > > fancier), and then for 3.8 I will rip out all the locking entirely, > > because looking at the fs/buffer.c patch I wrote up, it's all totally > > unnecessary. > > > > Adding a ACCESS_ONCE() to the read of the i_blkbits value (when > > creating new buffers) simply makes the whole locking thing pointless. > > Just make the page lock protect the block size, and make it per-page, > > and we're done. > > There's a 'block-dev' branch in my git tree, if you guys want to play > around with it. > > It actually reverts fs/block-dev.c back to the 3.6 state (except for > some whitespace damage that I refused to re-introduce), so that part > of the changes should be pretty safe and well tested. > > The fs/buffer.c changes, of course, are new. It's largely the same > patch I already sent out, with a small helper function to simplify it, > and to keep the whole ACCESS_ONCE() thing in just a single place. The fs/buffer.c part makes sense during a quick read. But fs/direct-io.c plays with i_blkbits too. The semaphore was fixing real bugs there. -chris