Re: Sealed memfd & no-fault mmap

[Ming Lin]

On 5/29/2021 1:15 PM, Hugh Dickins wrote:
> NOFAULT? Does BSD use "fault" differently, and in Linux terms we
> would say NOSIGBUS to mean the same?
>
> Can someone point to a specification of BSD's __MAP_NOFAULT?
> Searching just found me references to bugs.

Checked freebsd and openbsd, their MAP_NOFAULT seems quite different
than NOSIGBUS.

freebsd: https://github.com/freebsd/freebsd-src
MAP_NOFAULT: The mapping should not generate page faults

openbsd: https://github.com/openbsd/src
__MAP_NOFAULT only makes sense with a backing object

> What mainly worries me about the suggestion is: what happens to the
> zero page inserted into NOFAULT mappings, when later a page for that
> offset is created and added to page cache?
>
> Treating it as an opaque blob of zeroes, that stays there ever after,
> hiding the subsequent data: easy to implement, but a hack that we would
> probably regret.  (And I notice that even the quote from David Herrmann
> in the original post allows for the possibility that client may want to
> expand the object.)

Yes, that's problem ...

> I believe the correct behaviour would be to unmap the nofault page
> then, allowing the proper page to be faulted in after.  That is
> certainly doable (the old mm/filemap_xip.c used to do so), but might
> get into some awkward race territory, with filesystem dependence
> (reminiscent of hole punch, in reverse).  shmem could operate that
> way, and be the better for it: but I wouldn't want to add that,
> without also cleaning away all the shmem_recalc_inode() stuff.

After we treat it as zero page, then no page fault for later read.
What is the timing to unmap the nofault page?

I'm reading filemap_xip.c to learn how to do it.
https://elixir.bootlin.com/linux/v3.19.8/source/mm/filemap_xip.c