Re: [PATCH 3/3] xfs: Fix stale data exposure when readahead races with hole punch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon 23-09-19 15:33:05, Boaz Harrosh wrote:
> 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?
> )

What I was testing was:
  Fill file with data.
  One process does fadvise(WILLNEED) block by block from end of the file.
  Another process punches hole into the file.

If they race is the right way, following read will show old data instead of
zeros. And as I said I'm able to hit this but only if I add artificial
delay between truncating page cache and actually removing blocks.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux