Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754812Ab2K2WhB (ORCPT ); Thu, 29 Nov 2012 17:37:01 -0500 Received: from mail-we0-f174.google.com ([74.125.82.174]:45813 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752157Ab2K2Wg7 (ORCPT ); Thu, 29 Nov 2012 17:36:59 -0500 MIME-Version: 1.0 In-Reply-To: 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:36:38 -0800 X-Google-Sender-Auth: xYb3Vb6LEq_kXo0DQFUpVj5Zojs 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: 1019 Lines: 25 On Thu, Nov 29, 2012 at 2:16 PM, Linus Torvalds wrote: > > 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. It turns out fs/ioctl.c does the same - it fills in the buffer head with some random bh->b_size too. I think it's not even a power of two in that case. And I guess it's understandable - they don't actually *use* the buffer, they just want the offset. So the b_size field really is just random crap to the users of the get_block interfaces, since they've never cared before. Ugh, this was definitely a dark and disgusting underbelly of the VFS layer. We've not had to really touch it for a *looong* time.. 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/