lkml.org 
[lkml]   [2020]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subjectx86 page_fault not succeeding when mapping write-only
Date
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.
\
 
 \ /
  Last update: 2020-11-16 15:50    [W:0.040 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site