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

[Amir Goldstein <amir73il@gmail.com>]

On Fri, Jan 17, 2020 at 12:50 PM Amir Goldstein <amir73il@gmail.com> 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.
> >
>
> Jan,
>
> Could you give a quick status update about the state of this issue for
> ext4 and other fs. I remember some solutions were discussed.
> Perhaps this could be a good topic for a cross track session in LSF/MM?
> Aren't the challenges posed by this race also relevant for RWF_UNCACHED?
>

Maybe a silly question:

Can someone please explain to me why we even bother truncating pages on
punch hole?
Wouldn't it solve the race if instead we zeroed those pages and marked them
readonly?

The comment above trunacte_pagecache_range() says:
 * This function should typically be called before the filesystem
 * releases resources associated with the freed range (eg. deallocates
 * blocks). This way, pagecache will always stay logically coherent
 * with on-disk format, and the filesystem would not have to deal with
 * situations such as writepage being called for a page that has already
 * had its underlying blocks deallocated.

So in order to prevent writepage from being called on a punched hole,
we need to make sure that page write fault will be called, which is the same
state as if an exiting hole has been read into page cache but not written yet.
Right? Wrong?

What am I missing here?

Thanks,
Amir.