On Sat, Oct 17, 2020 at 01:09:12AM +0200, Jann Horn wrote: > Currently, mm_struct has two refcounts: > > - mm_users: preserves everything - the mm_struct, the page tables, the > memory mappings, and so on > - mm_count: preserves the mm_struct and pgd > > However, there are three types of users of mm_struct: > > 1. users that want page tables, memory mappings and so on > 2. users that want to preserve the pgd (for lazy TLB) > 3. users that just want to keep the mm_struct itself around (e.g. for > mmget_not_zero() or __ptrace_may_access()) > > Dropping mm_count references can be messy because dropping mm_count to > zero deletes the pgd, which takes the pgd_lock on x86, meaning it doesn't > work from RCU callbacks (which run in IRQ context). In those cases, > mmdrop_async() must be used to punt the invocation of __mmdrop() to > workqueue context. > > That's fine when mmdrop_async() is a rare case, but the preceding patch > "ptrace: Keep mm around after exit_mm() for __ptrace_may_access()" makes it > the common case; we should probably avoid punting freeing to workqueue > context all the time if we can avoid it? > > To resolve this, add a third refcount that just protects the mm_struct and > the user_ns it points to, and which can be dropped with synchronous freeing > from (almost) any context. > > Signed-off-by: Jann Horn <jannh@xxxxxxxxxx> > --- > arch/x86/kernel/tboot.c | 2 ++ > drivers/firmware/efi/efi.c | 2 ++ > include/linux/mm_types.h | 13 +++++++++++-- > include/linux/sched/mm.h | 13 +++++++++++++ > kernel/fork.c | 14 ++++++++++---- > mm/init-mm.c | 2 ++ > 6 files changed, 40 insertions(+), 6 deletions(-) I think mmu notifiers and the stuff in drivers/infiniband/core/ can be converted to this as well.. Actually I kind of wonder if you should go the reverse and find the few callers that care about the pgd and give them a new api with a better name (mmget_pgd?). Jason