x86 page_fault not succeeding when mapping write-only

x86 page_fault not succeeding when mapping write-only

[James Sewart]

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.