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]

 



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

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

								Honza

[1] https://lore.kernel.org/linux-fsdevel/20191216193852.GA8664@kmo-pixel/
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux