Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755306Ab2K2WRO (ORCPT ); Thu, 29 Nov 2012 17:17:14 -0500 Received: from mail-we0-f174.google.com ([74.125.82.174]:57446 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754609Ab2K2WRM (ORCPT ); Thu, 29 Nov 2012 17:17:12 -0500 MIME-Version: 1.0 In-Reply-To: <20121129212931.GD3490@shiny> References: <20121128194314.GF4939@ZenIV.linux.org.uk> <20121129191503.GB3490@shiny> <20121129194840.GC3490@shiny> <20121129212931.GD3490@shiny> From: Linus Torvalds Date: Thu, 29 Nov 2012 14:16:50 -0800 X-Google-Sender-Auth: eyQWRw1XjVqydrtY-qoR_Gf5pd0 Message-ID: Subject: Re: [PATCH v2] Do a proper locking for mmap and block size change To: Chris Mason , Linus Torvalds , Chris Mason , Mikulas Patocka , Al Viro , Jens Axboe , Jeff Chua , Lai Jiangshan , Jan Kara , lkml , linux-fsdevel Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1613 Lines: 34 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. What a crock. That direct-IO code is hack-upon-hack. Whoever wrote it should be shot. I think the only sane way to fix is is to pass in the block size to get_blocks(). Which we admittedly should have done long ago, so that's not a bad fix, but without actually looking at what it involves, I think it's going to be pretty big patch. All the filesystems that support the interface need to update it, even if they can then ignore it, because direct-IO does all these hacks only for the raw device. And I think it will improve the interface, but damn, direct-IO is still horrible for playing these kinds of games. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/