From: Dave Chinner <david@fromorbit.com>
To: Kent Overstreet <kent.overstreet@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Al Viro <viro@zeniv.linux.org.uk>, Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Theodore Ts'o" <tytso@mit.edu>
Subject: Re: fallocate INSERT_RANGE/COLLAPSE_RANGE is completely broken [PATCH]
Date: Tue, 29 Mar 2016 16:15:58 +1100 [thread overview]
Message-ID: <20160329051558.GC30721@dastard> (raw)
In-Reply-To: <20160329042546.GA10581@kmo-pixel>
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
next prev parent reply other threads:[~2016-03-29 5:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 4:25 fallocate INSERT_RANGE/COLLAPSE_RANGE is completely broken [PATCH] Kent Overstreet
2016-03-29 5:15 ` Dave Chinner [this message]
2016-03-29 6:04 ` Kent Overstreet
2016-03-29 22:37 ` Dave Chinner
2016-03-29 23:46 ` Kent Overstreet
2016-03-30 23:17 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160329051558.GC30721@dastard \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=kent.overstreet@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.