All of lore.kernel.org
 help / color / mirror / Atom feed
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(-)

             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: link
Be 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.