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.
