On Thu, Feb 13, 2020 at 1:54 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Mon, Jan 27, 2020 at 06:59:57PM -0800, Arjun Roy wrote: > > int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *); > > +int vm_insert_pages(struct vm_area_struct *vma, unsigned long addr, > > + struct page **pages, unsigned long *num); > > int vm_insert_pfn(struct vm_area_struct *vma, unsigned long addr, > > unsigned long pfn); > > Sorry I didn't notice these patches earlier. I'm not thrilled about > the addition of a new vm_insert_* operation; we're moving towards a > vmf_insert_* API. There are almost no users left of vm_insert_page > (10, at a quick count). Once they're all gone, we can switch the > underlying primitives over to a vm_fault_t return type and get rid of the > errno-to-vm-fault translation step that currently goes on. > > So ... is this called in the fault path? Do you have a struct vm_fault > around? Can you handle a vm_fault_t return value instead of an errno? This is not a page fault, really. This customer of vm_insert_page() is the TCP receive zerocopy code, which is remapping pages from the NIC into the userspace process (in lieu of sys_recvmsg()'s copy). See: tcp_zerocopy_receive() in net/ipv4/tcp.c . I took a peek at vmf_insert_page(). I think that hides the presence of EBUSY, which would be a necessary signal for us. If that was exposed I think vm_fault_t could be fine, *but* I shall defer to Eric for actually deciding on it. -Arjun
