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=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 593D8C43331 for ; Thu, 26 Mar 2020 12:56:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 11B2B2073E for ; Thu, 26 Mar 2020 12:56:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="HSv98EME" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11B2B2073E 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 97F456B009A; Thu, 26 Mar 2020 08:56:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 92ED86B009B; Thu, 26 Mar 2020 08:56:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 844496B009C; Thu, 26 Mar 2020 08:56:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id 68D846B009A for ; Thu, 26 Mar 2020 08:56:57 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 5909C181AD0A8 for ; Thu, 26 Mar 2020 12:56:57 +0000 (UTC) X-FDA: 76637513274.30.grass31_3cae382636a54 X-HE-Tag: grass31_3cae382636a54 X-Filterd-Recvd-Size: 4971 Received: from mail-yb1-f196.google.com (mail-yb1-f196.google.com [209.85.219.196]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Thu, 26 Mar 2020 12:56:56 +0000 (UTC) Received: by mail-yb1-f196.google.com with SMTP id x63so3166414ybx.2 for ; Thu, 26 Mar 2020 05:56:56 -0700 (PDT) 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=Y9YWW6vz22mlq1guLvP+/fT4LGWaEEduUDPTk3TTYX4=; b=HSv98EMEHHKD7UrRFLWR8ZBt4EMruUsPmDtAvm0qup2h9sFn6HXYf98wloKcmRhC9c s9NomqprvtpQWkfHrqHk4EXaQ8ApGUgEUc7lgCJouaeYlOAeDpYcVxNcPoghjRyH/yRa aQ5GWklAUXwS8/Z/lnWserBu7VV4tBVRWz59he+CaMkmc5uIR6foZuF9Vi+QZ+V5KB7P pkbs8FYrAboUF0FhrJFzl5qHjoAwbuN3zggbIb76d2vgarOa9XHBPReLGMIbG99gYW32 ar0IBEYhHFRy7EK6xYjVPSB2O8lrG4nqCSdcfFVSgu86gEygJpJ9eyHYnd7P2/olTVoy v8lw== 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=Y9YWW6vz22mlq1guLvP+/fT4LGWaEEduUDPTk3TTYX4=; b=cjXwNU3qdDDiOXOwmTETvItPvjjwyq7we7jKIq0roCrEH0WhJGiWWQrSMiQUFq4nQM VeOFfk7l3yZMyd14lHay6rPlkyKCkm47Sx1hXobtSNAzfyyiZIPdn+5jb4c4QyrP5f0C g4Q0jIT5diGbFBbeO44IZRIoEh5Vr3Hta//NubZliYo83HpAfce+3y3OcnZF30Z7noQV Y4k5pVT8eCI46CZy8r2C3lc7yPMeKr2n/ZmN6JLOEYnGzmlXk2UsXh9Bfy/cHtrvoZdG WwijULzsziamSD4TqrwORooAXkZcVz2qg+ttPwn7b8uc9RCg+W5tVFQuRM6T/8kgrkbR zOHw== X-Gm-Message-State: ANhLgQ3K/JqQ0CqMetstDiOMwo/gIeqzmMieLjhLnfSKs7lyCG6q9RTy Rnas1WDpv8HGrHL0cKCZSxKBU6RhySwAt+b+4Fpp1A== X-Google-Smtp-Source: ADFU+vtF2qA3KBXX2BP5sJdWnpK/D2XCaS4hZJxxpwlwViIjO8YnBCF6JvUS+L7CIbDo7ziKEq2xz1Qd6tz/vPNxDBc= X-Received: by 2002:a25:ccd0:: with SMTP id l199mr14690377ybf.446.1585227415649; Thu, 26 Mar 2020 05:56:55 -0700 (PDT) MIME-Version: 1.0 References: <20200326070236.235835-1-walken@google.com> <20200326070236.235835-6-walken@google.com> <20200326120931.GF22483@bombadil.infradead.org> In-Reply-To: <20200326120931.GF22483@bombadil.infradead.org> From: Michel Lespinasse Date: Thu, 26 Mar 2020 05:56:43 -0700 Message-ID: Subject: Re: [PATCH 5/8] mmap locking API: convert nested write lock sites To: Matthew Wilcox Cc: Andrew Morton , linux-mm , LKML , Peter Zijlstra , Laurent Dufour , Vlastimil Babka , Liam Howlett , Jerome Glisse , Davidlohr Bueso , David Rientjes , Hugh Dickins , Ying Han 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 Thu, Mar 26, 2020 at 5:09 AM Matthew Wilcox wrote: > On Thu, Mar 26, 2020 at 12:02:33AM -0700, Michel Lespinasse wrote: > > @@ -47,9 +48,9 @@ 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); > > - down_write_nested(&new->mmap_sem, 1); > > + mmap_write_lock_nested(new, 1); > > uml_setup_stubs(new); > > - mmap_write_unlock(new); > > + mmap_write_unlock_nested(new); > > This is a bit of an oddity. We don't usually have an unlock_nested() > variant (a quick grep finds only something complicated in reiserfs). > That's because it's legitimate to release locks in a different order from > the one they were acquired in (eg lock A, lock B, unlock A, unlock B), and > it's not clear whether "nested" would follow the lock (ie unlock_nested B) > or whether it would follow the code (ie unlock_nested A). > > Does your future API require knowing the nested nature at the unlock > point? And if so, does it require it for A or B in the above scenario? > And how does it mix with lock A or B being of a different type (eg a > plain mutex or a spinlock)? I'll admit it's a bit unusual. In MM we have only two uses nested mmap locks (as you can see in this patch), and they both release locks in the opposite order as they acquire them. We could probably follow this pattern if additional use cases end up being needed. In my range locking patchset, nested locks need to pass an explicit lock range. Also when implementing mmap_sem locking latencies, it can be convenient to ignore the nested locks under the assumption that their hold interval is contained within the outer lock's hold interval. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies.