From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH v2] Do a proper locking for mmap and block size change Date: Fri, 30 Nov 2012 13:49:10 +1100 Message-ID: <20121130024910.GF6434@dastard> References: <20121128194314.GF4939@ZenIV.linux.org.uk> <20121129191503.GB3490@shiny> <20121129194840.GC3490@shiny> <20121129212931.GD3490@shiny> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Chris Mason , Chris Mason , 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 02:16:50PM -0800, Linus Torvalds wrote: > On Thu, Nov 29, 2012 at 1:29 PM, Chris Mason wrote: > > > > Just reading the new blkdev_get_blocks, it looks like we're mixing > > shifts. In direct-io.c map_bh->b_size is how much we'd like to map, and > > it has no relation at all to the actual block size of the device. The > > interface is abusing b_size to ask for as large a mapping as possible. > > Ugh. That's a big violation of how buffer-heads are supposed to work: > the block number is very much defined to be in multiples of b_size > (see for example "submit_bh()" that turns it into a sector number). > > But you're right. The direct-IO code really *is* violating that, and > knows that get_block() ends up being defined in i_blkbits regardless > of b_size. Same with mpage_readpages(), so it's not just direct IO that has this problem.... Cheers, Dave. -- Dave Chinner david@fromorbit.com