Message ID | 20230109205336.3665937-10-surenb@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp2375244wrt; Mon, 9 Jan 2023 12:56:01 -0800 (PST) X-Google-Smtp-Source: AMrXdXvuOHW6FxgC1xXJf6CRrA9MYgwGgiUi8T133/puk+8vi+kMPThIjNNWi0C/DuVKhxuc1kH0 X-Received: by 2002:a17:907:8b17:b0:78d:f454:3856 with SMTP id sz23-20020a1709078b1700b0078df4543856mr59007151ejc.19.1673297761219; Mon, 09 Jan 2023 12:56:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673297761; cv=none; d=google.com; s=arc-20160816; b=FFKQ2tL+EXL973C5KtVNK/H2nhztb6n2mfFLaut91aQC/eu4T4vF5zgaHe/26iwYuB s8X8aJ/zk5sk2QNk6aQPzYJ6md7YnvLFgP5R3dhqfBTb3HWhhEbwmgCJnBwp1UtpkEXd Q73KKc2MHxJhkXjb2li0fH4aDaOL3dqWkGoFlpAIOI7yD4gQk2oXYg42vPwDHOXyB4LM K9FF4BXv++96/xNvgrqznNiQvWuHWz7LxbFcSNLy38f1v7ilrnkQbIwnI52Rpw3+cFf+ NrQKljLbmJz/0f0iXMOuIJdqxGd9pMbo3nNB5ySb5K1rbdZi8UMYtC3r3amXvYPz8/Eb hxLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=D1pZqRdf8jzuIQZRLrMCJmLqIEvbyFYNYfXzudRZz6Y=; b=uvQXPA2Iset5soBnX1aQrfGFCi6SJ6uz5VG6d+1H2HHgUpLAmwTYBF2L45rTjPGeWP sGMa2Ocx6kwgKVNL+9g++oKv0DvqF7nHhej1VqT6zTOp00Vd1XifbJJcblgipvkVVBMi 21IkAqfntubqwMPpcDpQS2/qXItZRI4nFM02CDajaQQYrvkpDdy2s7ZtARjbeBE0HrOk cj5PLiE0Da5S7cHsqxrygxQ89uD8M4PVieZsmZ3zmgZAFS6YuAx0mlvXuTOzIL3B664F yDHaoVjjdbUbxaFaqYenpyugturM6TeWwUvnF3CE8aZ1jj8UhI8wV5qdMQjWLNMBFQB5 k/ZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="plHU/zWr"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id be14-20020a1709070a4e00b008173e855728si9710860ejc.528.2023.01.09.12.55.38; Mon, 09 Jan 2023 12:56:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="plHU/zWr"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237350AbjAIUyk (ORCPT <rfc822;syz17693488234@gmail.com> + 99 others); Mon, 9 Jan 2023 15:54:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60072 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237338AbjAIUyF (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 9 Jan 2023 15:54:05 -0500 Received: from mail-oi1-x24a.google.com (mail-oi1-x24a.google.com [IPv6:2607:f8b0:4864:20::24a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6DAE374598 for <linux-kernel@vger.kernel.org>; Mon, 9 Jan 2023 12:54:04 -0800 (PST) Received: by mail-oi1-x24a.google.com with SMTP id b8-20020a056808010800b0035e342ff33aso3044932oie.13 for <linux-kernel@vger.kernel.org>; Mon, 09 Jan 2023 12:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=D1pZqRdf8jzuIQZRLrMCJmLqIEvbyFYNYfXzudRZz6Y=; b=plHU/zWrfFxaQ0yt/JPDRB18eEsMPdd+ZJ4E4yT8T5NRkdKBZYZu2kA11sksr3NXzt jDgkb12AloyToG1qepTp/9j3c1S/nL9/sMLfiUGj3EbCeKSxNDyG2Qbnp2R8KUfjKQNu 1hUjiCYEdhUY2xqldYVyznhCdRudSDrsopmij1IaAdQfZY5giCy+PasuJa7G7ZNci7e/ L6oXIEMKihljCOjvvq+Mko/UGqlkYlK33Q2p9mFgU8soW7h5CIdjJbM9Bn0dub4CcI+s 5hJtucAeeWPqjUkI2FPiSFxFnJ3u2uppPiS920i95ViALBCSjuucJs6UET/oQp6p8GLF Q6Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=D1pZqRdf8jzuIQZRLrMCJmLqIEvbyFYNYfXzudRZz6Y=; b=NV+uWW8kSqjnzXC7qxYInTBwa5wfHfVMsbOIQqaJNekLb+x92UzFDOITuhZVR35I6M maTYcagBmSw0p6cnWX89HQoEBJvKXb9HC4Goe4mRSE0CFeDkkIureH+3F/kWsmUTykEu QAbPgrH77pV5CpM3UqJ3AkCYpu6Ncz2J4oGtouexcSyikyhKH6ByLtagDS9ErMbkOE6r ViT1xBKbZQiSTFzm/T9E7orv1aCzM0CokbzxMzmOEmKxy3hiupTsRLk0rumgEZdQ5Pqe jGyF6CL5IDaHnnYhQOsIgljGyx+qK5WAP1pRaPUNMFamMOHOJWSFZneA5woLsMQ9EORT td+Q== X-Gm-Message-State: AFqh2kppwJH6haqOwDXv8UaB65ED3bl/GpTGkLwz6VFs7LRqjzVnYVa1 IwmsGmNXlqfR8JqNfMj6XbWlDVi0uuY= X-Received: from surenb-desktop.mtv.corp.google.com ([2620:15c:211:200:9393:6f7a:d410:55ca]) (user=surenb job=sendgmr) by 2002:a05:6870:649e:b0:143:509f:17f0 with SMTP id cz30-20020a056870649e00b00143509f17f0mr4940900oab.211.1673297643629; Mon, 09 Jan 2023 12:54:03 -0800 (PST) Date: Mon, 9 Jan 2023 12:53:04 -0800 In-Reply-To: <20230109205336.3665937-1-surenb@google.com> Mime-Version: 1.0 References: <20230109205336.3665937-1-surenb@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230109205336.3665937-10-surenb@google.com> Subject: [PATCH 09/41] mm: rcu safe VMA freeing From: Suren Baghdasaryan <surenb@google.com> To: akpm@linux-foundation.org Cc: michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, paulmck@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, hughlynch@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com, surenb@google.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754579872842800970?= X-GMAIL-MSGID: =?utf-8?q?1754579872842800970?= |
Series |
Per-VMA locks
|
|
Commit Message
Suren Baghdasaryan
Jan. 9, 2023, 8:53 p.m. UTC
From: Michel Lespinasse <michel@lespinasse.org> This prepares for page faults handling under VMA lock, looking up VMAs under protection of an rcu read lock, instead of the usual mmap read lock. Signed-off-by: Michel Lespinasse <michel@lespinasse.org> Signed-off-by: Suren Baghdasaryan <surenb@google.com> --- include/linux/mm_types.h | 13 ++++++++++--- kernel/fork.c | 13 +++++++++++++ 2 files changed, 23 insertions(+), 3 deletions(-)
Comments
On Mon 09-01-23 12:53:04, Suren Baghdasaryan wrote: [...] > void vm_area_free(struct vm_area_struct *vma) > { > free_anon_vma_name(vma); > +#ifdef CONFIG_PER_VMA_LOCK > + call_rcu(&vma->vm_rcu, __vm_area_free); > +#else > kmem_cache_free(vm_area_cachep, vma); > +#endif Is it safe to have vma with already freed vma_name? I suspect this is safe because of mmap_lock but is there any reason to split the freeing process and have this potential UAF lurking? > } > > static void account_kernel_stack(struct task_struct *tsk, int account) > -- > 2.39.0
On Tue, Jan 17, 2023 at 6:25 AM Michal Hocko <mhocko@suse.com> wrote: > > On Mon 09-01-23 12:53:04, Suren Baghdasaryan wrote: > [...] > > void vm_area_free(struct vm_area_struct *vma) > > { > > free_anon_vma_name(vma); > > +#ifdef CONFIG_PER_VMA_LOCK > > + call_rcu(&vma->vm_rcu, __vm_area_free); > > +#else > > kmem_cache_free(vm_area_cachep, vma); > > +#endif > > Is it safe to have vma with already freed vma_name? I suspect this is > safe because of mmap_lock but is there any reason to split the freeing > process and have this potential UAF lurking? It should be safe because VMA is either locked or has been isolated while locked, so no page fault handlers should have access to it. But you are right, moving free_anon_vma_name() into __vm_area_free() does seem safer. Will make the change in the next rev. > > > } > > > > static void account_kernel_stack(struct task_struct *tsk, int account) > > -- > > 2.39.0 > > -- > Michal Hocko > SUSE Labs
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index 4b6bce73fbb4..d5cdec1314fe 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -535,9 +535,16 @@ struct anon_vma_name { struct vm_area_struct { /* The first cache line has the info for VMA tree walking. */ - unsigned long vm_start; /* Our start address within vm_mm. */ - unsigned long vm_end; /* The first byte after our end address - within vm_mm. */ + union { + struct { + /* VMA covers [vm_start; vm_end) addresses within mm */ + unsigned long vm_start; + unsigned long vm_end; + }; +#ifdef CONFIG_PER_VMA_LOCK + struct rcu_head vm_rcu; /* Used for deferred freeing. */ +#endif + }; struct mm_struct *vm_mm; /* The address space we belong to. */ diff --git a/kernel/fork.c b/kernel/fork.c index 58aab6c889a4..5986817f393c 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -479,10 +479,23 @@ struct vm_area_struct *vm_area_dup(struct vm_area_struct *orig) return new; } +#ifdef CONFIG_PER_VMA_LOCK +static void __vm_area_free(struct rcu_head *head) +{ + struct vm_area_struct *vma = container_of(head, struct vm_area_struct, + vm_rcu); + kmem_cache_free(vm_area_cachep, vma); +} +#endif + void vm_area_free(struct vm_area_struct *vma) { free_anon_vma_name(vma); +#ifdef CONFIG_PER_VMA_LOCK + call_rcu(&vma->vm_rcu, __vm_area_free); +#else kmem_cache_free(vm_area_cachep, vma); +#endif } static void account_kernel_stack(struct task_struct *tsk, int account)