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

[Jan Kara <jack@suse.cz>]

On Mon 20-01-20 15:54:28, Amir Goldstein wrote:
> On Mon, Jan 20, 2020 at 2:03 PM Jan Kara <jack@suse.cz> wrote:
> > 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.

So I have an idea how it could be solved: Change calling convention for
->readpage() so that it gets called without page locked and take
i_mmap_sem there (and in ->readpages()) to protect from the race. But
I wanted to present it in the form of patches as the devil here is in the
details and it may prove to be too ugly to be bearable.

If I won't get to writing the patches, you're right it may be sensible to
present the idea to people at LSF/MM what they think about it.

> > > 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.

Yes, that's right.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR