Re: [PATCH] mm: Avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux