From: Catalin Marinas <catalin.marinas@arm.com>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
"Darrick J. Wong" <djwong@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs/iomap: Fix write path page prefaulting
Date: Tue, 23 Nov 2021 17:29:18 +0000 [thread overview]
Message-ID: <YZ0k7ivc6slfSB7F@arm.com> (raw)
In-Reply-To: <20211123151812.361624-1-agruenba@redhat.com>
On Tue, Nov 23, 2021 at 04:18:12PM +0100, Andreas Gruenbacher wrote:
> When part of the user buffer passed to generic_perform_write() or
> iomap_file_buffered_write() cannot be faulted in for reading, the entire
> write currently fails.
>
> The correct behavior would be to write all the data that can be written,
> up to the point of failure. Since commit a6294593e8a1 ("iov_iter: Turn
> iov_iter_fault_in_readable into fault_in_iov_iter_readable"), we have
> enough information to implement that, so change the code to do that.
>
> We already take into account that pages faulted in may no longer be
> resident by the time they are accessed, so the code will also behave
> correctly when part of the buffer isn't faulted in in the first place.
>
> This leads to an intentional user-visible change when the buffer passed
> to write calls contains unmapped or poisoned pages.
>
> (This change obsoletes commit 554c577cee95 ("gfs2: Prevent endless loops
> in gfs2_file_buffered_write").)
>
> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
FWIW:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
This would be more consistent as in my tests on a vanilla kernel ext4
and btrfs fail with EFAULT while gfs2 copies as much as it can before
hitting the fault.
--
Catalin
next prev parent reply other threads:[~2021-11-23 17:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-23 15:18 [PATCH] fs/iomap: Fix write path page prefaulting Andreas Gruenbacher
2021-11-23 17:29 ` Catalin Marinas [this message]
2021-11-25 13:23 ` Christoph Hellwig
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=YZ0k7ivc6slfSB7F@arm.com \
--to=catalin.marinas@arm.com \
--cc=agruenba@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.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.