Thread (19 messages) 19 messages, 4 authors, 2020-01-20

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

From: Jan Kara <jack@suse.cz>
Date: 2020-01-20 12:03:42
Also in: linux-fsdevel, linux-xfs

Hi Amir!

On Fri 17-01-20 12:50:58, Amir Goldstein wrote:
On Thu, Aug 29, 2019 at 4:10 PM Jan Kara [off-list ref] wrote:
quoted
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/ (local)
-- 
Jan Kara [off-list ref]
SUSE Labs, CR
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help