From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751766AbcC2FQG (ORCPT ); Tue, 29 Mar 2016 01:16:06 -0400 Received: from ipmail04.adl6.internode.on.net ([150.101.137.141]:34528 "EHLO ipmail04.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750928AbcC2FQE (ORCPT ); Tue, 29 Mar 2016 01:16:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ASCgB4DvpWPDGaLHldgy5TfaZyAQEBAQEBBowOhWKEDSGFZgQCAoEmTQEBAQEBAQcBAQEBQUCEQgEBBDocIxAIAxgJJQ8FJQMHGhOIJg/BAQEBCAIBHRmFPIUMh2iCKwWXaoVyiAuCPoxZRI5JhFsoMAEBiHgBAQE Date: Tue, 29 Mar 2016 16:15:58 +1100 From: Dave Chinner To: Kent Overstreet Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Al Viro , Rik van Riel , Andrew Morton , "Theodore Ts'o" Subject: Re: fallocate INSERT_RANGE/COLLAPSE_RANGE is completely broken [PATCH] Message-ID: <20160329051558.GC30721@dastard> References: <20160329042546.GA10581@kmo-pixel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160329042546.GA10581@kmo-pixel> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 28, 2016 at 08:25:46PM -0800, Kent Overstreet wrote: > Bit of previous discussion: > http://thread.gmane.org/gmane.linux.file-systems/101201/ > > The underlying issue is that we have no mechanism for invalidating a range of > the pagecache and then _keeping it invalidated_ while we Do Stuff. > > The fallocate INSERT_RANGE/COLLAPSE_RANGE situation seems likely to be worse > than I initially thought. I've been digging into this in the course of bcachefs > testing - I was hitting assertions that meant state hanging off the page cache > (in this case, allocation information, i.e. whether we needed to reserve space > on write) was inconsistent with the btree in writepages(). > > Well, bcachefs isn't the only filesystem that hangs additional state off the > pagecache, and the situation today is that an unpriviliged user can cause > inconsistencies there by just doing buffered reads concurrently with > INSERT_RANGE/COLLAPSE_RANGE. I highly highly doubt this is an issue of just > "oops, you corrupted your file because you were doing stupid stuff" - who knows > what internal invariants are getting broken here, and I don't particularly care > to find out. I'd like to see a test case for this. Concurrent IO and/or page faults should not run at the same as fallocate on XFS. Hence I'd like to see the test cases that demonstrate buffered reads are causing corruption during insert/collapse range operations. We use the same locking strategy for fallocate as we use for truncate and all the other internal extent manipulation operations, so if there's something wrong, we need to fix it. Cheers, Dave. -- Dave Chinner david@fromorbit.com