> On Jan 9, 2020, at 3:01 PM, Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx> wrote: >> The vmap code immediately removes PTEs when unmaps occur (which it may >> very well do right now -- I haven't checked) but also tracks the >> kernel_tlb_gen associated with each record of an >> unmapped-but-not-zapped area. Then we split vm_unmap_aliases() into a >> variant that unmaps all aliases and a variant that merely promises to >> unmap at least one alias. The former does what the current code does >> except that it skips the IPI if all areas in question have tlb_gen < >> flushed_kernel_tlb_gen. The latter clears all areas with tlb_gen < >> flushed_kernel_tlb_gen and, if there weren't any, does >> flush_tlb_kernel_range() and flushes everything. >> >> (Major caveat: this is wrong for the case where >> flush_tlb_kernel_range() only flushes some but not all of the kernel. >> So this needs considerable work if it's actually going to me useful. >> The plain old "take locks and clean up" approach might be a better >> bet.) >> > > Hmm. In normal usage (!DEBUG_PAGE_ALLOC), are kernel range tlb shootdowns common > outside of module space users and lazy vmap stuff? A tlb_gen solution might only > be worth it in cases where something other than vm_unmap_aliases() and helpers > was doing this frequently. I suspect that the two bug users aside from vunmap() will be eBPF and, eventually, XPFO / “exclusive pages” / less crappy SEV-like implementations / actual high quality MKTME stuff / KVM side-channel-proof memory. The latter doesn’t actually exist yet (the SEV implementation sidesteps this with a horrible hack involving incoherent mappings that are left active with fingers crossed), but it really seems like it’s coming. In general, if we’re going to have a pool of non-RW-direct-mapped pages, we also want some moderately efficient way to produce such pages. Right now, creating and freeing eBPF programs in a loop is probably a performance disaster on large systems.
