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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42754E7717F for ; Mon, 16 Dec 2024 21:18:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC3376B00D7; Mon, 16 Dec 2024 16:18:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B71C56B00D8; Mon, 16 Dec 2024 16:18:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A12E66B00D9; Mon, 16 Dec 2024 16:18:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 817136B00D7 for ; Mon, 16 Dec 2024 16:18:52 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2BE34120207 for ; Mon, 16 Dec 2024 21:18:52 +0000 (UTC) X-FDA: 82902085770.07.8DD2650 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) by imf24.hostedemail.com (Postfix) with ESMTP id 9534C18000F for ; Mon, 16 Dec 2024 21:18:46 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b="Exo/K1NW"; spf=none (imf24.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734383916; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aq6kZVM12fgWzF+pq/rgcXR/bLmQmlEHBp3Dopc19M4=; b=tMZGO1DeAdfgy7kLqcIVB2GpxJhkQdQhOU/92ZuxYBhb5rGLDXacu70oGA3gXBsBf1FhYu /0yLb5B87kqDem9RPCBblb7fDNZn32QpV7rqG7Ux2iKq+tRd19kj+UPjgr7BxVp0kRL9Px U6cE9t5xbxyvaPEko3SV/gXd9S+BxaA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734383916; a=rsa-sha256; cv=none; b=E4cU6RFnbR5E940iwJohFy8inGCj3cotL3eFK/8vizoQ+E+7y9oD0rx5oBcgvAUkHYHD67 zCM3+Vhc3or0ZmpCZH/5Xz9Hf9rpX4xeBUb6746GV3faSCLJ7gHG2GSgKoUtaC2ytaYgfl COjmJO+vKDIW43LXjPAAVYl5+OdBiM4= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b="Exo/K1NW"; spf=none (imf24.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=aq6kZVM12fgWzF+pq/rgcXR/bLmQmlEHBp3Dopc19M4=; b=Exo/K1NWyblsPnEfeIij0yFOdP mvrvETCJ6OQxMElyMkEOlQEEqCGu5JjNEtupMxwAShKwoU8WJ0N20jA0jpVkUG5P/ZZlKKWDkcXcv w8sFnvZ1Zl2UZd5oBNsEDp2JFnr9MCRUWhKljJivlQx3bxdwYUKhCtmUaiHzPdZl5oQq5Qah8P1tF cjsDLAbMDqO9DT6BdJMPBZN/NsOzI7uB0FEFXcsVyw+6tv+WDSU+ivXUsi4cF3zKkDH2N6SIJELtH QtLhBxviq9TJ8PBHoUGwsk70cr4DlrecqtOGGP4tSa94PF/qqWDc+MHvRquzAzmP9v80pHCkmiNPp 7GToNoCg==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tNITz-00000004wgd-1GY9; Mon, 16 Dec 2024 21:18:33 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id D7EBE30031E; Mon, 16 Dec 2024 22:18:26 +0100 (CET) Date: Mon, 16 Dec 2024 22:18:26 +0100 From: Peter Zijlstra To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, willy@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mjguzik@gmail.com, oliver.sang@intel.com, mgorman@techsingularity.net, david@redhat.com, peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, lokeshgidra@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, klarasmodin@gmail.com, corbet@lwn.net, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v6 11/16] mm: enforce vma to be in detached state before freeing Message-ID: <20241216211826.GA33253@noisy.programming.kicks-ass.net> References: <20241216192419.2970941-1-surenb@google.com> <20241216192419.2970941-12-surenb@google.com> <20241216211635.GC9803@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241216211635.GC9803@noisy.programming.kicks-ass.net> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 9534C18000F X-Stat-Signature: sa6qib4drwk3at6faiswmeceoqe6xzmw X-Rspam-User: X-HE-Tag: 1734383926-767197 X-HE-Meta: U2FsdGVkX19+alq7JXqoc1jjs5NKcUQtsXf3bQVix5BhNI1jzbhvOx/kSottBrVWbtyqqAg60/EBuGunX0kdbDuySVV4QDd8BbH6NylmLlx2Hiyyacd8GiFJydKmC8Afa7v7RTOLM0CutvprszoUFM71RZL/a8r1Zj/aRcnGa2iWSaa5iSTYHYBNdEIS77hG4TSAmQs+VIN+YU5ZKJm1/f6p+mzfpsuJVoe2/pXrdu5s58LBYtphXdAGFWjj5unlsjNzyGzZCiWHqW28WMGrV9p+0qFT6djvQD8HepyRT8UP6uUmGpfQLJTg7DvCbaxrrChjbIul2XpbpesrfuMatd2+rH62Byzq1Y3HlErC6mit8Y5uvkzbkEZZFOdXlus4ykGpAIlQUoX8j99q2BoHYp6ar7tUDB8fVPWZsHFBA1zdsOrwxp7CrBAy8mVcdysH/ddzS11Wk5Bt40fIieYOmhChBca8kXfs5xQ0tuzk4+pHy1QC8YfbwcUZVc7+8lh+oZaaCj8u2Elu67UDELO+LM6lfrrL7KHJ1TTyP2C2+juD/xH26Qj43tporrx6GYB1vg4rzd1BAq7nf69xbfqwkf1F8WzSH0VYmTn0z0HWRTpkrfoFhtGG9FY9aRNdOYkB7TAFsMUGU0Nfh/oAWX6skIVfS30zIbAm55JR3e258rtrcImIABCHJABb7n2oN/2a+do9y7qKcZGb9HLy5O92ilklrYaACne9585ojkS7axtIO2D+oOWJ9fICkY2syIFmt0xnu2g2LEgTXcRfAS9N0Gx1AdWvCtbu0MEOrQX/5IcUPFXHmsKEAM2Nr1jE1nCiJkH8M2z6OVAhMHdoFlgdzl6dlcwK+zHXj3l0wVI8NeXg7ic/pxxnfUGZM2wzBBW9yFZMqx3tQ3lR2fQkG0rjtuVyFG6d0avtJe8F3oBzWFnDVXXnv3D/bp91e2uVoxlHNtBEuf0i2WTh+Nn486P ad75qpPJ 9sLUfh6l6/oW2jCpKAaTHOrfbg6NwcyF1dVgk1ff4ExYDFFU6TAqjaRLMC9YmO+LsOcT5QFn3/BeMdIc1SbGb2Ljw/4D7Co3DS4hqJG6mvc/Ij6FbzGrZE4zWD93MRfcjSznE0tIZlIhRVCSWBZfY9+96GOFm+FZV4K6ksox77lIT/S7lSDniiaTA+Fa60PJPAnQXMGlz+ZbuQ23Mbymvo5kkN1+l3rj36HfOsFBVqLgxo18c95LOENyLeDoStyfraTpIMxeikGU4Jn59h5r7hI/LWk9M0q/1netnd9tDiMScEREBlBjMSSN8rw== 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: List-Subscribe: List-Unsubscribe: On Mon, Dec 16, 2024 at 10:16:35PM +0100, Peter Zijlstra wrote: > On Mon, Dec 16, 2024 at 11:24:14AM -0800, Suren Baghdasaryan wrote: > > exit_mmap() frees vmas without detaching them. This will become a problem > > when we introduce vma reuse. Ensure that vmas are always detached before > > being freed. > > > > Signed-off-by: Suren Baghdasaryan > > --- > > kernel/fork.c | 4 ++++ > > mm/vma.c | 10 ++++++++-- > > 2 files changed, 12 insertions(+), 2 deletions(-) > > > > diff --git a/kernel/fork.c b/kernel/fork.c > > index 283909d082cb..f1ddfc7b3b48 100644 > > --- a/kernel/fork.c > > +++ b/kernel/fork.c > > @@ -473,6 +473,10 @@ struct vm_area_struct *vm_area_dup(struct vm_area_struct *orig) > > > > void __vm_area_free(struct vm_area_struct *vma) > > { > > +#ifdef CONFIG_PER_VMA_LOCK > > + /* The vma should be detached while being destroyed. */ > > + VM_BUG_ON_VMA(!is_vma_detached(vma), vma); > > +#endif > > vma_numab_state_free(vma); > > free_anon_vma_name(vma); > > kmem_cache_free(vm_area_cachep, vma); > > diff --git a/mm/vma.c b/mm/vma.c > > index fbd7254517d6..0436a7d21e01 100644 > > --- a/mm/vma.c > > +++ b/mm/vma.c > > @@ -413,9 +413,15 @@ void remove_vma(struct vm_area_struct *vma, bool unreachable) > > if (vma->vm_file) > > fput(vma->vm_file); > > mpol_put(vma_policy(vma)); > > - if (unreachable) > > + if (unreachable) { > > +#ifdef CONFIG_PER_VMA_LOCK > > + if (!is_vma_detached(vma)) { > > + vma_start_write(vma); > > + vma_mark_detached(vma); > > + } > > +#endif > > __vm_area_free(vma); > > Again, can't you race with lockess RCU lookups? Ah, no, removing vma requires holding mmap_lock for writing and having the vma locked, which would ensure preceding RCU readers are complete (per the LOCK_OFFSET waiter thing) and new RCU readers are rejected for the vma sequence thing.