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

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- 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 --]