From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, linux-xfs <linux-xfs@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Boaz Harrosh <boaz@plexistor.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH 0/3 v2] xfs: Fix races between readahead and hole punching
Date: Mon, 20 Jan 2020 13:03:33 +0100 [thread overview]
Message-ID: <20200120120333.GG19861@quack2.suse.cz> (raw)
In-Reply-To: <CAOQ4uxiDqtpsH_Ot5N+Avq0h5MBXsXwgDdNbdRC0QDZ-e+zefg@mail.gmail.com>
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@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).
> 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@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2020-01-20 12:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 13:10 [PATCH 0/3 v2] xfs: Fix races between readahead and hole punching Jan Kara
2019-08-29 13:10 ` [PATCH 1/3] mm: Handle MADV_WILLNEED through vfs_fadvise() Jan Kara
2019-08-29 15:49 ` Darrick J. Wong
2019-08-29 13:10 ` [PATCH 2/3] fs: Export generic_fadvise() Jan Kara
2019-08-29 13:10 ` [PATCH 3/3] xfs: Fix stale data exposure when readahead races with hole punch Jan Kara
2019-08-29 15:52 ` Darrick J. Wong
2019-08-30 15:24 ` Jan Kara
2019-08-30 16:02 ` Darrick J. Wong
2019-09-18 12:31 ` Jan Kara
2019-09-18 16:07 ` Darrick J. Wong
2019-09-23 12:33 ` Boaz Harrosh
2019-09-24 15:23 ` Jan Kara
2019-09-24 15:45 ` Boaz Harrosh
2020-01-17 10:50 ` [PATCH 0/3 v2] xfs: Fix races between readahead and hole punching Amir Goldstein
2020-01-19 8:35 ` Amir Goldstein
2020-01-20 11:47 ` Jan Kara
2020-01-20 12:03 ` Jan Kara [this message]
2020-01-20 13:54 ` Amir Goldstein
2020-01-20 16:58 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200120120333.GG19861@quack2.suse.cz \
--to=jack@suse.cz \
--cc=amir73il@gmail.com \
--cc=axboe@kernel.dk \
--cc=boaz@plexistor.com \
--cc=darrick.wong@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).