On Wed, Aug 23, 2017 at 02:26:52PM -0700, rdodgen@xxxxxxxxx wrote: > From: Randy Dodgen <dodgen@xxxxxxxxxx> > > If an ext4 filesystem is mounted with both the DAX and read-only > options, executables on that filesystem will fail to start (claiming > 'Segmentation fault') due to the fault handler returning > VM_FAULT_SIGBUS. > > This is due to the DAX fault handler (see ext4_dax_huge_fault) > attempting to write to the journal when FAULT_FLAG_WRITE is set. This is > the wrong behavior for write faults which will lead to a COW page; in > particular, this fails for readonly mounts. > > This change avoids journal writes for faults that are expected to COW. > > It might be the case that this could be better handled in > ext4_iomap_begin / ext4_iomap_end (called via iomap_ops inside > dax_iomap_fault). These is some overlap already (e.g. grabbing journal > handles). > > Signed-off-by: Randy Dodgen <dodgen@xxxxxxxxxx> > --- > > This version is simplified as suggested by Ross; all fault sizes and fallbacks > are handled by dax_iomap_fault. We really need to do the same for ext2 and xfs. And we really should be doing that in common VM code instead of the file system. See my recent xfs synchronous page fault series on the mess the inconsistent handling of the FAULT_FLAG_WRITE causes. I think we just need a new FAULT_FLAG_ALLOC or similar for those page faults that needs to allocate space instead of piling hacks over hacks, and make sure it's only set over the method that will actually do the allocation, as the DAX and non-DAX path are not consistent on that. Also any chance you could write an xfstest for this?
