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

  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.