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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 20, 2020 at 2:03 PM Jan Kara <jack@xxxxxxx> 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@xxxxxxx> 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.



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux