On Fri, Sep 6, 2019 at 11:28 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Fri, Sep 06, 2019 at 10:52:41PM +0200, Andreas Gruenbacher wrote: > > Hi, > > > > I've just fixed a mmap write vs. truncate consistency issue on gfs on > > filesystems with a block size smaller that the page size [1]. > > > > It turns out that the same problem exists between mmap write and hole > > punching, and since xfstests doesn't seem to cover that, > > AFAIA, fsx exercises it pretty often. Certainly it's found problems > with XFS in the past w.r.t. these operations. > > > I've written a > > new test [2]. > > I suspect that what we really want is a test that runs > _test_generic_punch using mmap rather than pwrite... > > > Ext4 and xfs both pass that test; they both apparently > > mark the pages that have a hole punched in them as read-only so that > > page_mkwrite is called before those pages can be written to again. > > XFS invalidates the range being hole punched (see > xfs_flush_unmap_range() under XFS_MMAPLOCK_EXCL, which means any > attempt to fault that page back in will block on the MMAPLOCK until > the hole punch finishes. This isn't about writes during the hole punching, this is about writes once the hole is punched. For example, the test case I've posted creates the following file layout with 1k blocksize: DDDD DDDD DDDD Then it punches a hole like this: DDHH HHHH HHDD Then it fills the hole again with mwrite: DDDD DDDD DDDD As far as I can tell, that needs to trigger page faults on all three pages. I did get these on ext4; judging from the fact that xfs works, the also seem to occur there; but on gfs2, page_mkwrite isn't called for the two partially mapped pages, only for the page in the middle that's entirely within the hole. And I don't see where those pages are marked read-only; it appears like pagecache_isize_extended isn't called on ext4 or xfs. So how does this work there? > > gfs2 fails that: for some reason, the partially block-mapped pages are > > not marked read-only on gfs2, and so page_mkwrite is not called for the > > partially block-mapped pages, and the hole is not filled in correctly. > > > > The attached patch fixes the problem, but this really doesn't look right > > as neither ext4 nor xfs require this kind of hack. So what am I > > overlooking, how does this work on ext4 and xfs? > > XFS uses XFS_MMAPLOCK_* to serialise page faults against extent > manipulations (shift, hole punch, truncate, swap, etc) and ext4 uses > a similar locking mechanism to do the same thing. Fundamentally, the > page cache does not provide the necessary mechanisms to detect and > prevent invalidation races inside EOF.... Yes, but that unfortunately doesn't answer my question. Thanks, Andreas > > > > Signed-off-by: Andreas Gruenbacher <agruenba@xxxxxxxxxx> > > --- > > fs/gfs2/bmap.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c > > index 9ef543dd38e2..e677e813be4c 100644 > > --- a/fs/gfs2/bmap.c > > +++ b/fs/gfs2/bmap.c > > @@ -2475,6 +2475,13 @@ int __gfs2_punch_hole(struct file *file, loff_t offset, loff_t length) > > if (error) > > goto out; > > } > > + /* > > + * If the first or last page partially lies in the hole, mark > > + * the page read-only so that memory-mapped writes will trigger > > + * page_mkwrite. > > + */ > > + pagecache_isize_extended(inode, offset, inode->i_size); > > + pagecache_isize_extended(inode, offset + length, inode->i_size); > > See xfs_flush_unmap_range(), which is run under XFS_MMAPLOCK_EXCL > to serialise against incoming page faults... > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
