On Wed, Apr 25, 2018 at 06:01:02AM -0700, Eric Dumazet wrote: > On 04/24/2018 11:28 PM, Christoph Hellwig wrote: > > On Tue, Apr 24, 2018 at 10:27:21PM -0700, Eric Dumazet wrote: > >> When adding tcp mmap() implementation, I forgot that socket lock > >> had to be taken before current->mm->mmap_sem. syzbot eventually caught > >> the bug. > >> > >> Since we can not lock the socket in tcp mmap() handler we have to > >> split the operation in two phases. > >> > >> 1) mmap() on a tcp socket simply reserves VMA space, and nothing else. > >> This operation does not involve any TCP locking. > >> > >> 2) setsockopt(fd, IPPROTO_TCP, TCP_ZEROCOPY_RECEIVE, ...) implements > >> the transfert of pages from skbs to one VMA. > >> This operation only uses down_read(¤t->mm->mmap_sem) after > >> holding TCP lock, thus solving the lockdep issue. > >> > >> This new implementation was suggested by Andy Lutomirski with great details. > > > > Thanks, this looks much more sensible to me. > > > > Thanks Christoph > > Note the high cost of zap_page_range(), needed to avoid -EBUSY being returned > from vm_insert_page() the second time TCP_ZEROCOPY_RECEIVE is used on one VMA. > > Ideally a vm_replace_page() would avoid this cost ? If you don't zap the page range, any of the CPUs in the system where any thread in this task have ever run may have a TLB entry pointing to this page ... if the page is being recycled into the page allocator, then that page might end up as a slab page or page table or page cache while the other CPU still have access to it. You could hang onto the page until you've built up a sufficiently large batch, then bulk-invalidate all of the TLB entries, but we start to get into weirdnesses on different CPU architectures.
