On Wed Apr 29, 2020 at 7:48 AM, Christophe Leroy wrote: > > > > > Le 29/04/2020 à 04:05, Christopher M. Riedl a écrit : > > x86 supports the notion of a temporary mm which restricts access to > > temporary PTEs to a single CPU. A temporary mm is useful for situations > > where a CPU needs to perform sensitive operations (such as patching a > > STRICT_KERNEL_RWX kernel) requiring temporary mappings without exposing > > said mappings to other CPUs. A side benefit is that other CPU TLBs do > > not need to be flushed when the temporary mm is torn down. > > > > Mappings in the temporary mm can be set in the userspace portion of the > > address-space. > > > > Interrupts must be disabled while the temporary mm is in use. HW > > breakpoints, which may have been set by userspace as watchpoints on > > addresses now within the temporary mm, are saved and disabled when > > loading the temporary mm. The HW breakpoints are restored when unloading > > the temporary mm. All HW breakpoints are indiscriminately disabled while > > the temporary mm is in use. > > > Why do we need to use a temporary mm all the time ? > Not sure I understand, the temporary mm is only in use for kernel patching in this series. We could have other uses in the future maybe where it's beneficial to keep mappings local. > > Doesn't each CPU have its own mm already ? Only the upper address space > is shared between all mm's but each mm has its own lower address space, > at least when it is running a user process. Why not just use that mm ? > As we are mapping then unmapping with interrupts disabled, there is no > risk at all that the user starts running while the patch page is mapped, > so I'm not sure why switching to a temporary mm is needed. > > I suppose that's an option, but then we have to save and restore the mapping which we temporarily "steal" from userspace. I admit I didn't consider that as an option when I started this series based on the x86 patches. I think it's cleaner to switch mm, but that's a rather weak argument. Are you concerned about performance with the temporary mm? > > > > > > Based on x86 implementation: > > > > commit cefa929c034e > > ("x86/mm: Introduce temporary mm structs") > > > > Signed-off-by: Christopher M. Riedl <cmr@xxxxxxxxxxxxxx> > > > Christophe > > > >