Messages in this thread |  | | Subject | Re: Sealed memfd & no-fault mmap | From | Ming Lin <> | Date | Sat, 29 May 2021 16:36:14 -0700 |
| |
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
|  |