From: Andreas Gruenbacher <agruenba@redhat.com> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andreas Gruenbacher <agruenba@redhat.com>, cluster-devel@redhat.com, linux-kernel@vger.kernel.org Subject: [GIT PULL] gfs2 fix Date: Tue, 26 Apr 2022 16:54:45 +0200 [thread overview] Message-ID: <20220426145445.2282274-1-agruenba@redhat.com> (raw) Hi Linus, please consider pulling the following gfs2 fix for 5.18-rc5. Also, note that we're fighting with a rare case of data corruption that seems to have been introduced by commit 00bfe02f4796 ("gfs2: Fix mmap + page fault deadlocks for buffered I/O"; merged in v5.16). The corruption seems to occur in gfs2_file_buffered_write() when fault_in_iov_iter_readable() is involved. We do end up with data that's written at an offset, as if after a fault-in, the position in the iocb got out of sync with the position in the iov_iter. The user buffer the iov_iter points at isn't page aligned, so the corruption also isn't page aligned. The code all seems correct and we couldn't figure out what's going on so far. Thanks, Andreas The following changes since commit af2d861d4cd2a4da5137f795ee3509e6f944a25b: Linux 5.18-rc4 (2022-04-24 14:51:22 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git tags/gfs2-v5.18-rc4-fix for you to fetch changes up to e57f9af73d6b0ffb5f1aeaf6cec9a751dd8535c9: gfs2: Don't re-check for write past EOF unnecessarily (2022-04-26 15:38:00 +0200) ---------------------------------------------------------------- gfs2 fix - Only re-check for direct I/O writes past the end of the file after re-acquiring the inode glock. ---------------------------------------------------------------- Andreas Gruenbacher (1): gfs2: Don't re-check for write past EOF unnecessarily fs/gfs2/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
WARNING: multiple messages have this Message-ID (diff)
From: Andreas Gruenbacher <agruenba@redhat.com> To: cluster-devel.redhat.com Subject: [Cluster-devel] [GIT PULL] gfs2 fix Date: Tue, 26 Apr 2022 16:54:45 +0200 [thread overview] Message-ID: <20220426145445.2282274-1-agruenba@redhat.com> (raw) Hi Linus, please consider pulling the following gfs2 fix for 5.18-rc5. Also, note that we're fighting with a rare case of data corruption that seems to have been introduced by commit 00bfe02f4796 ("gfs2: Fix mmap + page fault deadlocks for buffered I/O"; merged in v5.16). The corruption seems to occur in gfs2_file_buffered_write() when fault_in_iov_iter_readable() is involved. We do end up with data that's written at an offset, as if after a fault-in, the position in the iocb got out of sync with the position in the iov_iter. The user buffer the iov_iter points at isn't page aligned, so the corruption also isn't page aligned. The code all seems correct and we couldn't figure out what's going on so far. Thanks, Andreas The following changes since commit af2d861d4cd2a4da5137f795ee3509e6f944a25b: Linux 5.18-rc4 (2022-04-24 14:51:22 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git tags/gfs2-v5.18-rc4-fix for you to fetch changes up to e57f9af73d6b0ffb5f1aeaf6cec9a751dd8535c9: gfs2: Don't re-check for write past EOF unnecessarily (2022-04-26 15:38:00 +0200) ---------------------------------------------------------------- gfs2 fix - Only re-check for direct I/O writes past the end of the file after re-acquiring the inode glock. ---------------------------------------------------------------- Andreas Gruenbacher (1): gfs2: Don't re-check for write past EOF unnecessarily fs/gfs2/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
next reply other threads:[~2022-04-26 14:55 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-26 14:54 Andreas Gruenbacher [this message] 2022-04-26 14:54 ` [Cluster-devel] [GIT PULL] gfs2 fix Andreas Gruenbacher 2022-04-26 18:31 ` Linus Torvalds 2022-04-26 18:31 ` [Cluster-devel] " Linus Torvalds 2022-04-26 21:27 ` Andreas Gruenbacher 2022-04-26 21:27 ` [Cluster-devel] " Andreas Gruenbacher 2022-04-26 23:33 ` Linus Torvalds 2022-04-26 23:33 ` [Cluster-devel] " Linus Torvalds 2022-04-27 12:29 ` Andreas Gruenbacher 2022-04-27 12:29 ` [Cluster-devel] " Andreas Gruenbacher 2022-04-27 17:13 ` Linus Torvalds 2022-04-27 17:13 ` [Cluster-devel] " Linus Torvalds 2022-04-27 19:41 ` Andreas Gruenbacher 2022-04-27 19:41 ` [Cluster-devel] " Andreas Gruenbacher 2022-04-27 20:25 ` Linus Torvalds 2022-04-27 20:25 ` [Cluster-devel] " Linus Torvalds 2022-04-27 21:26 ` Andreas Gruenbacher 2022-04-27 21:26 ` [Cluster-devel] " Andreas Gruenbacher 2022-04-27 22:20 ` Linus Torvalds 2022-04-27 22:20 ` [Cluster-devel] " Linus Torvalds 2022-04-28 0:00 ` Linus Torvalds 2022-04-28 0:00 ` [Cluster-devel] " Linus Torvalds 2022-04-28 13:26 ` Andreas Gruenbacher 2022-04-28 13:26 ` [Cluster-devel] " Andreas Gruenbacher 2022-04-28 17:09 ` Linus Torvalds 2022-04-28 17:09 ` [Cluster-devel] " Linus Torvalds 2022-04-28 17:17 ` Linus Torvalds 2022-04-28 17:17 ` [Cluster-devel] " Linus Torvalds 2022-04-28 17:21 ` Andreas Gruenbacher 2022-04-28 17:21 ` [Cluster-devel] " Andreas Gruenbacher 2022-04-28 17:38 ` Andreas Gruenbacher 2022-04-28 17:38 ` [Cluster-devel] " Andreas Gruenbacher 2022-05-02 18:31 ` Linus Torvalds 2022-05-02 18:31 ` [Cluster-devel] " Linus Torvalds 2022-05-02 18:58 ` Linus Torvalds 2022-05-02 18:58 ` [Cluster-devel] " Linus Torvalds 2022-05-02 20:24 ` Andreas Gruenbacher 2022-05-02 20:24 ` [Cluster-devel] " Andreas Gruenbacher 2022-05-03 8:56 ` Andreas Gruenbacher 2022-05-03 8:56 ` [Cluster-devel] " Andreas Gruenbacher 2022-05-03 13:30 ` Andreas Gruenbacher 2022-05-03 13:30 ` [Cluster-devel] " Andreas Gruenbacher 2022-05-03 16:19 ` Linus Torvalds 2022-05-03 16:19 ` [Cluster-devel] " Linus Torvalds 2022-05-03 16:41 ` Andreas Gruenbacher 2022-05-03 16:41 ` [Cluster-devel] " Andreas Gruenbacher 2022-05-03 16:50 ` Linus Torvalds 2022-05-03 16:50 ` [Cluster-devel] " Linus Torvalds 2022-05-03 21:35 ` Andreas Gruenbacher 2022-05-03 21:35 ` [Cluster-devel] " Andreas Gruenbacher 2022-05-03 22:41 ` Linus Torvalds 2022-05-03 22:41 ` [Cluster-devel] " Linus Torvalds 2022-05-04 17:52 ` Andreas Gruenbacher 2022-05-04 17:52 ` [Cluster-devel] " Andreas Gruenbacher 2022-04-28 18:16 ` pr-tracker-bot 2022-04-28 18:16 ` [Cluster-devel] " pr-tracker-bot 2022-04-26 19:07 ` pr-tracker-bot 2022-04-26 19:07 ` [Cluster-devel] " pr-tracker-bot 2023-06-06 12:48 Andreas Gruenbacher 2023-06-06 12:55 ` Linus Torvalds 2023-06-06 13:32 ` Andreas Gruenbacher 2023-06-06 13:22 ` pr-tracker-bot 2024-03-25 12:10 Andreas Gruenbacher 2024-03-25 18:18 ` pr-tracker-bot
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=20220426145445.2282274-1-agruenba@redhat.com \ --to=agruenba@redhat.com \ --cc=cluster-devel@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=torvalds@linux-foundation.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.