On 5/31/2021 11:24 PM, Linus Torvalds wrote:
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?
Simon,
Is this "simple" solution good enough for Wayland compositor use case?
