From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65802C4742C for ; Tue, 3 Nov 2020 02:11:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8CF8F206F1 for ; Tue, 3 Nov 2020 02:11:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="CbTjX+TW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8CF8F206F1 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4D5436B005C; Mon, 2 Nov 2020 21:11:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4892A6B005D; Mon, 2 Nov 2020 21:11:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 379146B0068; Mon, 2 Nov 2020 21:11:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0228.hostedemail.com [216.40.44.228]) by kanga.kvack.org (Postfix) with ESMTP id 0752A6B005C for ; Mon, 2 Nov 2020 21:11:31 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 962121EE6 for ; Tue, 3 Nov 2020 02:11:31 +0000 (UTC) X-FDA: 77441480382.05.pigs02_3e182cc272b4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 7933618022BF9 for ; Tue, 3 Nov 2020 02:11:31 +0000 (UTC) X-HE-Tag: pigs02_3e182cc272b4 X-Filterd-Recvd-Size: 6250 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Nov 2020 02:11:30 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id y16so17330945ljk.1 for ; Mon, 02 Nov 2020 18:11:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wDptHzkTNo5v1VaGKz+DKFNTC+BV6fyCCdPZtdwjYHY=; b=CbTjX+TWC+ontKMRBBul5/niS/C7ZttvuYhDGOd5WKw7O0CGjzyetTuGzJESk1PhH5 k9wgMUXwRg5ymIKV1shjWDoTC5NJZlQSWUkYD2koPSvK1MGj3mg7i92udafmALkJqTwV jvjJ64OaeMMAgZvjMKbSCjU+yiotjRl40JN/O3zFwmFe46OdhEMHqLU+SIM0rAJDs6ni ke2aVbWz1ZzTRg3/cRspBdJ6QtAd2Z9aBjyYcygR2aGIFLWdUYLjR8XLkTxjabJ02Lmd pUzW8RANdMxH97FDB6ZX6/DZp5K/9hHbK2DanZEGSWgTpR+F2iUJkYsiMJ1Q0GloeZlu 6Lig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wDptHzkTNo5v1VaGKz+DKFNTC+BV6fyCCdPZtdwjYHY=; b=b9kUfE4YHeJuYARURg1CLEQ4qwHsc1JzX1o26ddJ8KphoAdIvsgizlr8Bly8DSIPmn 31UTIFjPkjaMb4Q+Xt4qKX468FBz1ZcfL8ZSy6k2dJEetcL6tJe5+HfqBRNmlj1Xeo6a BcwrsMShtrvDdsMt1EwOxchLusJF2APLiqoxKcnXC0AxykGxKKc2UkJDhhjsUwRmAHT1 HS9YIkVWchFTY9brGrz3icUcMTpCWGc8x3iEexeanR3C7U0XscPJTJZl3vByPEb97yIG 1BV5k4urmT1vKqdARZ5zFZFSpVunod1jMILBuj2SPpcJOyIMN3POqubBArewQkFoIwW9 rB2Q== X-Gm-Message-State: AOAM532y8WpLmfVwL7TVqElBMdhS4i8c5ECG4cJvuTP/MHJTUn9rOAOD Tr2a9BKfRmSR8GfpIzVIJQVmHJnqesTxQJOawsLQpw== X-Google-Smtp-Source: ABdhPJzkf3oJ+YnmdBbEIiwKjgwvrLp0kI0wsfDkNRKZmuZVbm0hldGNOheyzR1IbcUCyLaag8+as7p2s4Jbf2reh1w= X-Received: by 2002:a2e:a175:: with SMTP id u21mr6748044ljl.160.1604369489215; Mon, 02 Nov 2020 18:11:29 -0800 (PST) MIME-Version: 1.0 References: <20201016230915.1972840-1-jannh@google.com> <20201016230915.1972840-4-jannh@google.com> <20201016232153.GD37159@ziepe.ca> In-Reply-To: From: Jann Horn Date: Tue, 3 Nov 2020 03:11:02 +0100 Message-ID: Subject: Re: [RFC PATCH resend 3/6] mm: Add refcount for preserving mm_struct without pgd To: Jason Gunthorpe Cc: Andrew Morton , Linux-MM , Eric Biederman , Oleg Nesterov , kernel list , Will Deacon , Kees Cook , Ingo Molnar Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Oct 17, 2020 at 2:30 AM Jann Horn wrote: > On Sat, Oct 17, 2020 at 1:21 AM Jason Gunthorpe 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 > > > --- > > > 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. Actually, no - I think it ends up being around 30 mentions of the "take reference without PGD" function and around 35 mentions of the "take reference with PGD" function (assuming that all the weird powerpc stuff I don't understand needs the mm_context to not yet be destroyed). (A decent chunk of which are all the per-arch functions for starting secondary processors.) So I don't think doing it the way you suggested would really make the patch(es) smaller. And I think that it is helpful for review purposes to have separate patches for every converted site, and leave things as-is by default. If the semantics change for every user that is *not* touched by the patch, that makes it really easy for mistakes to slip through. I could try to convert more callers though?