On Sat, Oct 17, 2020 at 1:21 AM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > 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?). Yeah, that might make more sense... as long as I'm really sure about all the places I haven't changed. ^^ I'll try to change it as you suggested for v2.
