Is there anyway to ensure iov iter won't break a page copy?

Is there anyway to ensure iov iter won't break a page copy?

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 701 bytes --]

Hi,

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?

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?

Thanks,
Qu


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Is there anyway to ensure iov iter won't break a page copy?

[Matthew Wilcox]

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.

Re: Is there anyway to ensure iov iter won't break a page copy?

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 1598 bytes --]



On 2020/8/19 下午7:22, Matthew Wilcox wrote:
> 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.

Thanks a lot for the example! That solves my question instantly!

> 
>> 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.

That looks reasonably enough.

Thanks,
Qu


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]