From: Matthew Wilcox <willy@infradead.org>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Is there anyway to ensure iov iter won't break a page copy?
Date: Wed, 19 Aug 2020 12:22:52 +0100 [thread overview]
Message-ID: <20200819112252.GZ17456@casper.infradead.org> (raw)
In-Reply-To: <5a2d6a48-9407-7c81-f12a-9e66abdf927f@gmx.com>
On Wed, Aug 19, 2020 at 06:59:48PM +0800, Qu Wenruo wrote:
> There are tons of short copy check for iov_iter_copy_from_user_atomic(),
> from the generic_performan_write() which checks the copied in the
> write_end().
>
> To iomap, which checks the copied in its iomap_write_end().
>
> But I'm wondering, all these call sites have called
> iov_iter_falut_in_read() to ensure the range we're copying from are
> accessible, and we prepared the pages by ourselves, how could a short
> copy happen?
Here's how it happens. The system is low on memory. We fault in the
range that we're interested in, which (for the sake of argument is a
file mapping; similar things can happen for anonymous memory) allocates
page cache pages and fills them with data. Now another task runs and
also allocates memory. The pages we want get reclaimed (we don't have
a refcount on them, so this can happen). Now when we go to access
them again, they're not there.
> Is there any possible race that user space can invalidate some of its
> memory of the iov?
>
> If so, can we find a way to lock the iov to ensure all its content can
> be accessed without problem until the iov_iter_copy_from_user_atomic()
> finishes?
Probably a bad idea. The I/O might be larger than all of physical memory,
so we might not be able to pin all of the pages for the duration of
the I/O.
next prev parent reply other threads:[~2020-08-19 11:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 10:59 Is there anyway to ensure iov iter won't break a page copy? Qu Wenruo
2020-08-19 11:22 ` Matthew Wilcox [this message]
2020-08-19 11:39 ` Qu Wenruo
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=20200819112252.GZ17456@casper.infradead.org \
--to=willy@infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox