On 06.12.22 22:27, Peter Xu wrote:
On Tue, Dec 06, 2022 at 05:28:07PM +0100, David Hildenbrand wrote:
If no one is using mprotect() with uffd-wp like that, then the reproducer may not be valid - the reproducer is defining how it should work, but does that really stand? That's why I said it's ambiguous, because the definition in this case is unclear.
There are interesting variations like:
mmap(PROT_READ, MAP_POPULATE|MAP_SHARED) uffd_wp() mprotect(PROT_READ|PROT_WRITE)
Where we start out with all-write permissions before we enable selective write permissions.
Could you elaborate what's the difference of above comparing to:
mmap(PROT_READ|PROT_WRITE, MAP_POPULATE|MAP_SHARED) uffd_wp()
?
That mapping would temporarily allow write access. I'd imagine that something like that might be useful when atomically replacing an existing mapping (MAP_FIXED), and the VMA might already be in use by other threads. or when you really want to catch any possible write access.
For example, libvhost-user.c in QEMU uses for ordinary postcopy:
/* * In postcopy we're using PROT_NONE here to catch anyone * accessing it before we userfault. */ mmap_addr = mmap(0, dev_region->size + dev_region->mmap_offset, PROT_NONE, MAP_SHARED | MAP_NORESERVE, vmsg->fds[0], 0);
I'd imagine, when using uffd-wp (VM snapshotting with shmem?) one might use PROT_READ instead before the write-protection is properly set. Because read access would be fine in the meantime.
But I'm just pulling use cases out of my magic hat ;) Nothing stops user space from doing things that are not clearly forbidden (well, even then users might complain, but that's a different story).
[...]
Case (2) is rather a corner case, and unless people complain about it being a real performance issue, it felt cleaner (less code) to not optimize for that now.
As I didn't have a closer look on the savedwrite removal patchset so I may not speak anything sensible here.. What I hope is that we don't lose write bits easily, after all we tried to even safe the dirty and young bits to avoid the machine cycles in the MMUs.
Hopefully, someone will complain loudly if that corner case is relevant.
Again Peter, I am not against you, not at all. Sorry if I gave you the impression. I highly appreciate your work and this discussion.
No worry on that part. You're doing great in this email explaining things and write things up, especially I'm happy Hugh confirmed it so it's good to have those. Let's start with something like this when you NAK something next time. :)
:)