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:
signature.asc
Description: OpenPGP digital signature
