Re: [PATCH 0/3 v2] xfs: Fix races between readahead and hole punching

From: Amir Goldstein <amir73il@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-xfs <linux-xfs@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Boaz Harrosh <boaz@plexistor.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	Jens Axboe <axboe@kernel.dk>,
	Kent Overstreet <kent.overstreet@gmail.com>
Subject: Re: [PATCH 0/3 v2] xfs: Fix races between readahead and hole punching
Date: Mon, 20 Jan 2020 15:54:28 +0200	[thread overview]
Message-ID: <CAOQ4uxhhsxaO61HwMvRGP=5duFsY6Nvv+vCutVZXWXWA2pu2KA@mail.gmail.com> (raw)
In-Reply-To: <20200120120333.GG19861@quack2.suse.cz>

On Mon, Jan 20, 2020 at 2:03 PM Jan Kara <jack@suse.cz> wrote:
>
> Hi Amir!
>
> On Fri 17-01-20 12:50:58, Amir Goldstein wrote:
> > On Thu, Aug 29, 2019 at 4:10 PM Jan Kara <jack@suse.cz> wrote:
> > >
> > > Hello,
> > >
> > > this is a patch series that addresses a possible race between readahead and
> > > hole punching Amir has discovered [1]. The first patch makes madvise(2) to
> > > handle readahead requests through fadvise infrastructure, the third patch
> > > then adds necessary locking to XFS to protect against the race. Note that
> > > other filesystems need similar protections but e.g. in case of ext4 it isn't
> > > so simple without seriously regressing mixed rw workload performance so
> > > I'm pushing just xfs fix at this moment which is simple.
> > >
> >
> > Could you give a quick status update about the state of this issue for
> > ext4 and other fs. I remember some solutions were discussed.
>
> Shortly: I didn't get to this. I'm sorry :-|. I'll bump up a priority but I
> can't promise anything at the moment.
>
> > Perhaps this could be a good topic for a cross track session in LSF/MM?
>
> Maybe although this is one of the cases where it's easy to chat about
> possible solutions but somewhat tedious to write one so I'm not sure how
> productive that would be. BTW my discussion with Kent [1] is in fact very
> related to this problem (the interval lock he has is to stop exactly races
> like this).
>

Well, I was mostly interested to know if there is an agreement on the way to
solve the problem. If we need to discuss it to reach consensus than it might
be a good topic for LSF/MM. If you already know what needs to be done,
there is no need for a discussion.

> > Aren't the challenges posed by this race also relevant for RWF_UNCACHED?
>
> Do you have anything particular in mind? I don't see how RWF_UNCACHED would
> make this any better or worse than DIO / readahead...
>

Not better nor worse. I meant that RFW_UNCACHED is another case that
would suffer the same races.

Thanks,
Amir.