On Wed, Sep 07, 2022 at 11:43:52AM -0700, Dan Williams wrote: > It is still the case that while waiting for the page to go idle it is > associated with its given file / inode. It is possible that > memory-failure, or some other event that requires looking up the page's > association, fires in that time span. Can't the page->mapping can remain set to the address space even if it is not installed into any PTEs? Zap should only remove the PTEs, not clear the page->mapping. Or, said another way, page->mapping should only change while the page refcount is 0 and thus the filesystem is completely in control of when it changes, and can do so under its own locks If the refcount is 0 then memory failure should not happen - it would require someone accessed the page without referencing it. The only thing that could do that is the kernel, and if the kernel is referencing a 0 refcount page (eg it got converted to meta-data or something), it is probably not linked to an address space anymore anyhow? > under filesystem locks. I.e. break layouts is "make it safe to do the > truncate", not "do the truncate up front". The truncate action is reorganizing the metadata in the filesystem, the lead up to it is to fence of all access to the DAX pages from all sources, so it does seem to me that 0ing the refcount in advance is exactly the right thing to do. It returns the page back to the exclusive control of the filesystem, and nothing else does this. Jason
