On Fri 03-02-17 07:13:59, Matthew Wilcox wrote: > On Fri, Feb 03, 2017 at 04:07:29PM +0100, Jan Kara wrote: > > Some ->page_mkwrite handlers may return VM_FAULT_RETRY as its return > > code (GFS2 or Lustre can definitely do this). However VM_FAULT_RETRY > > from ->page_mkwrite is completely unhandled by the mm code and results > > in locking and writeably mapping the page which definitely is not what > > the caller wanted. Fix Lustre and block_page_mkwrite_ret() used by other > > filesystems (notably GFS2) to return VM_FAULT_NOPAGE instead which > > results in bailing out from the fault code, the CPU then retries the > > access, and we fault again effectively doing what the handler wanted. > > Reading this commit message makes me wonder if this is the best fix. > It would seem logical that if I want the fault to be retried that I should > return VM_FAULT_RETRY, not VM_FAULT_NOPAGE. Why don't we have the MM > treat VM_FAULT_RETRY the same way that it treats VM_FAULT_NOPAGE and give > driver / filesystem writers one fewer way to shoot themselves in the foot? VM_FAULT_RETRY is special, it may be used only if FAULT_FLAG_ALLOW_RETRY was set in page fault flags and it means - we have dropped mmap_sem, we loaded page needed to satisfy the fault and now we need to try again (have a look at __lock_page_or_retry()). I have my reservations about this interface but it works... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
