From: Boaz Harrosh <openosd@gmail.com>
To: Jan Kara <jack@suse.cz>, "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org, linux-mm@kvack.org,
Amir Goldstein <amir73il@gmail.com>,
Boaz Harrosh <boaz@plexistor.com>,
linux-fsdevel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 3/3] xfs: Fix stale data exposure when readahead races with hole punch
Date: Mon, 23 Sep 2019 15:33:05 +0300 [thread overview]
Message-ID: <53b7b7b9-7ada-650c-0a32-291a242601f3@gmail.com> (raw)
In-Reply-To: <20190918123123.GC31891@quack2.suse.cz>
On 18/09/2019 15:31, Jan Kara wrote:
<>
>>> Is there a test on xfstests to demonstrate this race?
>>
>> No, but I can try to create one.
>
> I was experimenting with this but I could not reproduce the issue in my
> test VM without inserting artificial delay at appropriate place... So I
> don't think there's much point in the fstest for this.
>
> Honza
>
If I understand correctly you will need threads that direct-write
files, then fadvise(WILL_NEED) - in parallel to truncate (punch_hole) these
files - In parallel to trash caches.
(Direct-write is so data is not present in cache when you come to WILL_NEED
it into the cache, otherwise the xfs b-trees are not exercised. Or are you
more worried about the page_cache races?
)
Also the d-writes might want to exercise multiple size extents + holes as
well.
I have a very different system but its kind of the test we did for this
problem.
The reason it is never hit is because fadvise(WILL_NEED) is never really
used that much, and there are no applications that actually blindly truncate
during IO, this is only us in testing that do this meaningless thing.
Thanks Jan again for working on this
Boaz
next prev parent reply other threads:[~2019-09-23 12:33 UTC|newest]
Thread overview: 24+ 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 [this message]
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
2020-01-20 13:54 ` Amir Goldstein
2020-01-20 16:58 ` Jan Kara
-- strict thread matches above, loose matches on Subject: below --
2019-07-11 14:00 [PATCH 0/3] " Jan Kara
2019-07-11 14:00 ` [PATCH 3/3] xfs: Fix stale data exposure when readahead races with hole punch Jan Kara
2019-07-11 15:28 ` Amir Goldstein
2019-07-11 15:49 ` Darrick J. Wong
2019-07-12 12:00 ` Jan Kara
2019-07-12 17:56 ` Darrick J. Wong
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=53b7b7b9-7ada-650c-0a32-291a242601f3@gmail.com \
--to=openosd@gmail.com \
--cc=amir73il@gmail.com \
--cc=boaz@plexistor.com \
--cc=darrick.wong@oracle.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=stable@vger.kernel.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).