[lkml]   [2021]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Sealed memfd & no-fault mmap
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

MAP_NOFAULT: The mapping should not generate page faults

__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.

 \ /
  Last update: 2021-05-30 01:37    [W:0.160 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site