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=-23.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL 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 66B3EC4320A for ; Tue, 3 Aug 2021 21:49:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E682661040 for ; Tue, 3 Aug 2021 21:49:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E682661040 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 2E7268D000B; Tue, 3 Aug 2021 17:49:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 296F88D0005; Tue, 3 Aug 2021 17:49:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 185E68D000B; Tue, 3 Aug 2021 17:49:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0236.hostedemail.com [216.40.44.236]) by kanga.kvack.org (Postfix) with ESMTP id F03A38D0005 for ; Tue, 3 Aug 2021 17:48:59 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9ACA68249980 for ; Tue, 3 Aug 2021 21:48:59 +0000 (UTC) X-FDA: 78435109998.40.A6196F6 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf07.hostedemail.com (Postfix) with ESMTP id 5DCDD1006C5D for ; Tue, 3 Aug 2021 21:48:59 +0000 (UTC) Received: by mail-ed1-f46.google.com with SMTP id d6so920204edt.7 for ; Tue, 03 Aug 2021 14:48:59 -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=VW+IU9o1VXMz7OQGffphJNbpddNiraQMr89kP0rpdPo=; b=NU63CIV/+ui+ZJ4/JqDfg4zBRvhcoiKjbYIzyAplC0UYwS0h8jp6J7eOFkPhIa59gZ 065oDiAe4+WzH2muwOzfUBmkzcHM4QUpkxXB9EpqoEbc5fQQJH+/p3v+tEpViDzzslYn nM7Pkc7azd/3UclwCVdXKqX50xHjIig3NwVOLptGy7W46ZalqyRHC+IL2kUtOKqLYT4G tt4uiPYkHXsUcegHPnZDr1qPIzsgn/i4fCHntopxW8ydifCZegsoOrz5EviF8fTyNLJi GfTvYkhfhRJj1e0EnT69nLYpxfzbGISVDltRF51HWAvrTHPVbJuRkxXcgrJd1oifUwVE 4QvQ== 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=VW+IU9o1VXMz7OQGffphJNbpddNiraQMr89kP0rpdPo=; b=fELqSn/6pG9SS8onTevCVe/1zLCSx/kXCUsCeuH9KA+GwY39s1T7cKxKVIq48045+X myVj4Cx3HpVmTE3BfInw9s01LM5djQ9Sfv5fqs5VG4M5ZjGyb5gARM1Nw0MSuBsCY2Iq UtMNnEF8HxtWM69qgOUpssJktuDskUi0ggEdXGRsgYeKQuNCkjLrFNH1BCZzGG5mSDgI 3BrvE2ByrL9R+JvGcCPeC5+HlocyAx+keG1js1qNPO6UcZIsR6e5t4fY8jRk155sU+y/ qtwE4qDr4UrvZfPMPzDTEmZpftTz9D4Zkqom75zGH+Nbr9SCqsjfmn9FoQcagYtRzP10 7gkA== X-Gm-Message-State: AOAM533zWCD8nmJcLeYdOwd7HuqNCMD61QwBtoLajhX3IiMdAg+WmV9F f/B19D+YcdyF0F8zlFqUFQk85VkyWoKOtXS6sP5AwQ== X-Google-Smtp-Source: ABdhPJx5Jr5gF2XSfZ8PK1rDbz9Jq/BxnT+iIg5ZMO0kZ+25Fjhoa6eXpXCH1nCv7fR8ApawJvEGPjFW7T3g4JRqCeA= X-Received: by 2002:a05:6402:40d4:: with SMTP id z20mr21098304edb.89.1628027337814; Tue, 03 Aug 2021 14:48:57 -0700 (PDT) MIME-Version: 1.0 References: <20210731175341.3458608-1-lrizzo@google.com> <20210803160803.GG543798@ziepe.ca> In-Reply-To: <20210803160803.GG543798@ziepe.ca> From: Luigi Rizzo Date: Tue, 3 Aug 2021 23:48:46 +0200 Message-ID: Subject: Re: [PATCH] Add mmap_assert_locked() annotations to find_vma*() To: Jason Gunthorpe Cc: Jann Horn , linux-kernel , Andrew Morton , David Rientjes , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5DCDD1006C5D Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b="NU63CIV/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of lrizzo@google.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=lrizzo@google.com X-Stat-Signature: pdhttckuriszfuceycdom6c8qtocfjsb X-HE-Tag: 1628027339-987588 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 Tue, Aug 3, 2021 at 6:08 PM Jason Gunthorpe wrote: > > On Sat, Jul 31, 2021 at 10:53:41AM -0700, Luigi Rizzo wrote: > > find_vma() and variants need protection when used. > > This patch adds mmap_assert_lock() calls in the functions. > > > > To make sure the invariant is satisfied, we also need to add a > > mmap_read_loc() around the get_user_pages_remote() call in > > get_arg_page(). The lock is not strictly necessary because the mm > > has been newly created, but the extra cost is limited because > > the same mutex was also acquired shortly before in __bprm_mm_init(), > > so it is hot and uncontended. > > > > Signed-off-by: Luigi Rizzo > > fs/exec.c | 2 ++ > > mm/mmap.c | 2 ++ > > 2 files changed, 4 insertions(+) > > > > diff --git a/fs/exec.c b/fs/exec.c > > index 38f63451b928..ac7603e985b4 100644 > > +++ b/fs/exec.c > > @@ -217,8 +217,10 @@ static struct page *get_arg_page(struct linux_binprm *bprm, unsigned long pos, > > * We are doing an exec(). 'current' is the process > > * doing the exec and bprm->mm is the new process's mm. > > */ > > + mmap_read_lock(bprm->mm); > > ret = get_user_pages_remote(bprm->mm, pos, 1, gup_flags, > > &page, NULL, NULL); > > + mmap_read_unlock(bprm->mm); > > if (ret <= 0) > > return NULL; > > Wasn't Jann Horn working on something like this too? > > https://lore.kernel.org/linux-mm/20201016225713.1971256-1-jannh@google.com/ > > IIRC it was very tricky here, are you sure it is OK to obtain this lock > here? I cannot comment on Jann's patch series but no other thread knows about this mm at this point in the code so the lock is definitely safe to acquire (shortly before there was also a write lock acquired on the same mm, in the same conditions). cheers luigi > > I would much rather see Jann's complete solution be merged then > hacking at the exec problem on the side.. > > Jason