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