Hey,
I’m looking into an issue after remapping some memory on 4.19, but looking
at the code this may also be an issue in master.
I have a driver that grabs some pages using alloc_pages, these pages are
then remapped to userspace using calls to vm_insert_page inside a syfs
bin_attribute mmap handler. Userspace calls mmap64 on the sysfs file with
MAP_SHARED and read/write permissions. If the process reads or writes to
the mapping at this point it is fine and works. The issue occurs if the
process calls mprotect with write-only permissions, before reading/writing
to the mapping, then when writing I see the page fault handler doesn’t set
up the page tables and the process spins entering the fault handler and
exiting forever.
I tracked the return of page_fault down to a section in function
do_page_mkwrite:
ret = vmf->vma->vm_ops->page_mkwrite(vmf);
/* Restore original flags so that caller is not surprised */
vmf->flags = old_flags;
if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE)))
return ret;
if (unlikely(!(ret & VM_FAULT_LOCKED))) {
lock_page(page);
if (!page->mapping) {
unlock_page(page);
return 0; /* retry */ <- we return here
}
A 0 return here means wp_page_shared will return before setting up the pte.
This is a snippet of the call stack:
do_page_mkwrite at mm/memory.c:2404
wp_page_shared at mm/memory.c:2696
do_wp_page at mm/memory.c:2797
handle_pte_fault at mm/memory.c:4063
__handle_mm_fault at mm/memory.c:4171
We hit the (marked unlikely) condition in do_wp_page of the vma being
VM_WRITE and VM_SHARED only, which is why I think I only see the issue
when calling mprotect with write-only. Thinking about it now I haven’t
tried calling mmap with write-only to see what happens.
I think the issue is this vma has vm_ops associated with the kernfs ops,
but as the page was allocated outside of the filesystem stuff, it doesn’t
have the kernfs address_space_operations associated with it.
kernfs_vma_page_mkwrite returns 0 indicating it didn’t lock the page, but
do_page_mkwrite requires the page to have a mapping in this case.
I’m not sure what the solution is, I can’t figure out how to associate the
page with kernfs so this condition is satisfied. What is this check for?
Should kernfs_vma_page_mkwrite lock the page? Or maybe it should set
page->mapping?
Is there something I can do in my driver to the pages or vma to avoid
hitting this issue? I looked through some other kernel code and it seems
to me use of the vmalloc api or dma-iommu may hit the same issue.
Cheers,
James.
