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=-9.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 1FE13C4363C for ; Wed, 7 Oct 2020 07:42:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 99E0E2083B for ; Wed, 7 Oct 2020 07:42:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99E0E2083B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sipsolutions.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CD9FC900004; Wed, 7 Oct 2020 03:42:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8A6C900002; Wed, 7 Oct 2020 03:42:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B9F59900004; Wed, 7 Oct 2020 03:42:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id 8C452900002 for ; Wed, 7 Oct 2020 03:42:53 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 294693622 for ; Wed, 7 Oct 2020 07:42:53 +0000 (UTC) X-FDA: 77344337826.24.comb83_21012f4271cd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 00F161A4A0 for ; Wed, 7 Oct 2020 07:42:52 +0000 (UTC) X-HE-Tag: comb83_21012f4271cd X-Filterd-Recvd-Size: 3945 Received: from sipsolutions.net (s3.sipsolutions.net [144.76.43.62]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Wed, 7 Oct 2020 07:42:52 +0000 (UTC) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1kQ460-000lFA-IE; Wed, 07 Oct 2020 09:42:44 +0200 Message-ID: <115d17aa221b73a479e26ffee52899ddb18b1f53.camel@sipsolutions.net> Subject: Re: [PATCH v2 1/2] mmap locking API: Order lock of nascent mm outside lock of live mm From: Johannes Berg To: Jann Horn , Andrew Morton , linux-mm@kvack.org Cc: Michel Lespinasse , Jason Gunthorpe , Richard Weinberger , Jeff Dike , linux-um@lists.infradead.org, linux-kernel@vger.kernel.org, "Eric W . Biederman" , Sakari Ailus , John Hubbard , Mauro Carvalho Chehab , Anton Ivanov Date: Wed, 07 Oct 2020 09:42:42 +0200 In-Reply-To: <20201006225450.751742-2-jannh@google.com> References: <20201006225450.751742-1-jannh@google.com> <20201006225450.751742-2-jannh@google.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Wed, 2020-10-07 at 00:54 +0200, Jann Horn wrote: > Until now, the mmap lock of the nascent mm was ordered inside the mmap lock > of the old mm (in dup_mmap() and in UML's activate_mm()). > A following patch will change the exec path to very broadly lock the > nascent mm, but fine-grained locking should still work at the same time for > the old mm. > > In particular, mmap locking calls are hidden behind the copy_from_user() > calls and such that are reached through functions like copy_strings() - > when a page fault occurs on a userspace memory access, the mmap lock > will be taken. > > To do this in a way that lockdep is happy about, let's turn around the lock > ordering in both places that currently nest the locks. > Since SINGLE_DEPTH_NESTING is normally used for the inner nesting layer, > make up our own lock subclass MMAP_LOCK_SUBCLASS_NASCENT and use that > instead. > > The added locking calls in exec_mmap() are temporary; the following patch > will move the locking out of exec_mmap(). > > Signed-off-by: Jann Horn > --- > arch/um/include/asm/mmu_context.h | 3 +-- > fs/exec.c | 4 ++++ > include/linux/mmap_lock.h | 23 +++++++++++++++++++++-- > kernel/fork.c | 7 ++----- > 4 files changed, 28 insertions(+), 9 deletions(-) > > diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h > index 17ddd4edf875..c13bc5150607 100644 > --- a/arch/um/include/asm/mmu_context.h > +++ b/arch/um/include/asm/mmu_context.h > @@ -48,9 +48,8 @@ static inline void activate_mm(struct mm_struct *old, struct mm_struct *new) > * when the new ->mm is used for the first time. > */ > __switch_mm(&new->context.id); > - mmap_write_lock_nested(new, SINGLE_DEPTH_NESTING); > + mmap_assert_write_locked(new); > uml_setup_stubs(new); > - mmap_write_unlock(new); > } FWIW, this was I believe causing lockdep issues. I think I had previously determined that this was pointless, since it's still nascent and cannot be used yet? But I didn't really know for sure, and this patch was never applied: https://patchwork.ozlabs.org/project/linux-um/patch/20200604133752.397dedea0758.I7a24aaa26794eb3fa432003c1bf55cbb816489e2@changeid/ I guess your patches will also fix the lockdep complaints in UML in this area, I hope I'll be able to test it soon. johannes