Hi Marc, On 18/12/2019 15:30, Marc Zyngier wrote: > On 2019-12-18 15:07, James Morse wrote: >> On 13/12/2019 18:25, Marc Zyngier wrote: >>> If userspace issues a munmap() on a set of pages, there is no >>> expectation that the pages are cleaned to the PoC. >>> So let's >>> not do more work than strictly necessary, and set the magic >>> flag that avoids CMOs in this case. >> >> I think this assumes the pages went from anonymous->free, so no-one >> cares about the contents. >> >> If the pages are backed by a file, won't dirty pages will still get >> written back before the page is free? (e.g. EFI flash 'file' mmap()ed in) > > I believe so. Is that a problem? If we skipped the dcache maintenance on unmap, when the the dirty page is later reclaimed the clean+stale lines are written back to the file. File-backed dirty pages will stick around in the page cache in the hope someone else needs them. This would happen for a guest:device-mapping that is written to, but is actually backed by a mmap()d file. I think the EFI flash emulation does exactly this. >> What if this isn't the only mapping of the page? Can't it be swapped >> out from another VMA? (tenuous example, poor man's memory mirroring?) > > Swap-out wouldn't trigger this code path, as it would use a different > MMU notifier event (MMU_NOTIFY_CLEAR vs MMU_NOTIFY_UNMAP), I believe. This was a half thought-through special case of the above. The sequence would be: VM-A and VM-B both share a mapping of $page. 1. VM-A writes to $page through a device mapping 2. The kernel unmaps $page from VM-A for swap. KVM does the maintenance 3. VM-B writes to $page through a device mapping 4. VM-B exits, KVM skips the maintenance, $page may have clean+stale lines 5. Swap finds no further mappings, and writes $page and its clean+stale lines to disk. Two VMs with a shared mapping is the 'easy' example. I think you just need a second mapping for this to happen: it means the page isn't really free after the VM has exited. Thanks, James
