Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753117Ab2K2RTy (ORCPT ); Thu, 29 Nov 2012 12:19:54 -0500 Received: from mail-wi0-f170.google.com ([209.85.212.170]:62343 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751187Ab2K2RTx (ORCPT ); Thu, 29 Nov 2012 12:19:53 -0500 MIME-Version: 1.0 In-Reply-To: References: <50B46E05.70906@kernel.dk> <50B4B313.3030707@kernel.dk> <50B5CC5A.8060607@kernel.dk> <20121128194314.GF4939@ZenIV.linux.org.uk> From: Linus Torvalds Date: Thu, 29 Nov 2012 09:19:30 -0800 X-Google-Sender-Auth: NMe_-iEKltGVNKX4Tk9fWRCeWoQ Message-ID: Subject: Re: [PATCH v2] Do a proper locking for mmap and block size change To: Mikulas Patocka Cc: 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: 926 Lines: 24 On Wed, Nov 28, 2012 at 2:01 PM, Mikulas Patocka wrote: > > This sounds sensible. I'm sending this patch. This looks much better. 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. No RCU grace period crap, no expedited mess, no nothing. 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/