From: Andreas Gruenbacher <agruenba@redhat.com> To: cluster-devel@redhat.com, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org Cc: Andreas Gruenbacher <agruenba@redhat.com>, "Darrick J . Wong" <darrick.wong@oracle.com>, Dave Chinner <david@fromorbit.com>, Christoph Hellwig <hch@lst.de>, Lukas Czerner <lczerner@redhat.com> Subject: [Q] gfs2: mmap write vs. punch_hole consistency Date: Fri, 6 Sep 2019 22:52:41 +0200 [thread overview] Message-ID: <20190906205241.2292-1-agruenba@redhat.com> (raw) 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, I've written a new test [2]. 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. 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? Thanks, Andreas [1] gfs2: Improve mmap write vs. truncate consistency https://www.redhat.com/archives/cluster-devel/2019-September/msg00009.html [2] generic/567: test mmap write vs. hole punching https://www.spinics.net/lists/fstests/msg12474.html [PATCH] gfs2: Improve mmap write vs. punch_hole consistency Fixes xfstest generic/567. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> --- 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); } if (gfs2_is_jdata(ip)) { -- 2.20.1
WARNING: multiple messages have this Message-ID (diff)
From: Andreas Gruenbacher <agruenba@redhat.com> To: cluster-devel.redhat.com Subject: [Cluster-devel] [Q] gfs2: mmap write vs. punch_hole consistency Date: Fri, 6 Sep 2019 22:52:41 +0200 [thread overview] Message-ID: <20190906205241.2292-1-agruenba@redhat.com> (raw) 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, I've written a new test [2]. 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. 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? Thanks, Andreas [1] gfs2: Improve mmap write vs. truncate consistency https://www.redhat.com/archives/cluster-devel/2019-September/msg00009.html [2] generic/567: test mmap write vs. hole punching https://www.spinics.net/lists/fstests/msg12474.html [PATCH] gfs2: Improve mmap write vs. punch_hole consistency Fixes xfstest generic/567. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> --- 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); } if (gfs2_is_jdata(ip)) { -- 2.20.1
next reply other threads:[~2019-09-06 20:53 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-06 20:52 Andreas Gruenbacher [this message] 2019-09-06 20:52 ` [Cluster-devel] [Q] gfs2: mmap write vs. punch_hole consistency Andreas Gruenbacher 2019-09-06 21:27 ` Dave Chinner 2019-09-06 21:27 ` [Cluster-devel] " Dave Chinner 2019-09-06 21:48 ` Andreas Gruenbacher 2019-09-06 21:48 ` [Cluster-devel] " Andreas Gruenbacher 2019-09-06 23:15 ` Dave Chinner 2019-09-06 23:15 ` [Cluster-devel] " Dave Chinner 2019-09-09 9:19 ` Jan Kara 2019-09-09 9:19 ` [Cluster-devel] " 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=20190906205241.2292-1-agruenba@redhat.com \ --to=agruenba@redhat.com \ --cc=cluster-devel@redhat.com \ --cc=darrick.wong@oracle.com \ --cc=david@fromorbit.com \ --cc=hch@lst.de \ --cc=lczerner@redhat.com \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-xfs@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.