On Mon, May 31, 2021 at 11:13 AM Ming Lin <minggr@xxxxxxxxx> wrote:
>
> OK, I borrowed code from filemap_xip.c and implemented this behavior.
I think that "unmap page" is too complicated and fragile.
The only page that could possibly validly be unmapped is a stale zero
page, but that code in shmem_unmap_nofault_page() seems to try to
handle other cases too (ie that whole page_remove_rmap() - afaik a
zero page has no rmap).
I get the feeling that the simpler thing to do is to just say "if you
use MAP_NOSIGBUS, and you access pages that don't have a backing
store, you will get zero pages, and they will NOT BE SYNCHRONIZED with
the backing store possibly later being updated".
IOW, just document the fact that a MAP_NOSIGBUS mapping isn't coherent
wrt shmem contents that are expanded and filled in later.
Don't try to "fix" it - because any user that uses MAP_NOSIGBUS had
better just accept that it's not compatible with expanding the shmem
backing store later.
Keep it simple and stupid. Hmm?
Linus
