Message ID | 20230301190457.1498985-1-surenb@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp3816444wrd; Wed, 1 Mar 2023 11:13:19 -0800 (PST) X-Google-Smtp-Source: AK7set8ZfmB6ABhzptmMxP6TpISjys0A9sz4dBKMUJxEtgCjTS4npx1bo8BjftOqiJ7DzkPN6Iqq X-Received: by 2002:a17:90b:350b:b0:233:fdfd:7122 with SMTP id ls11-20020a17090b350b00b00233fdfd7122mr8620535pjb.37.1677697999444; Wed, 01 Mar 2023 11:13:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677697999; cv=none; d=google.com; s=arc-20160816; b=lJ7hxnnFu9GQOFIBruxRdNtzxWsTTEwI4vcMnpkeQRnxwr3nYQIr7h5mCBJ0zAQFDq 2tANTZ5kUV8R4WvegUxk6e/ur9YoQa3E+Xhp5fFUoZwa7LuFFHchsNd3Tn478Al1N3Ze 7uqjQhq3N0y1GJcGCW2xCDcfFncgW18+7GVvpFtzbo++Dua3qJgAoC046BKulJryEcxR vKZEIF/POu7gT1YlR65Yjs2+isXNsqVhVTe7lnCePvBYuw8w7iT5zhhVw3onZLV9v0zY O1zGU7AO457aXFvhdwMKt99EwnZUUmvHE1j8+GFNMmRkHLN5ATtM6jOTpISMqosUuhbl uQ4A== 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:mime-version:date :dkim-signature; bh=eZZzZE8GpdNY+MwogNnFVaUs2b/RvHe7OTvEU8aJPfc=; b=kg1VFvGjU19vxRM5MwWxKLCuaPuPPf3C4Ddw37yNoeahtRQ94zTVP9Fa/cx20Cndon DbjzR25XHt1imD4zkIq1UKdkfCD669hGCC2slMppTC7JC+Dw1XnKYUhUd/YO4z/O2BwE PH0Sf24Xm9+gt5DElAqUboJJ//vkgANqiyJVbz7CYMLDYoN1kSpPZ0piT8mS2yCzYbbF UOfxyLB+LTtXXYCbSPtG7qcy+zbQTQk+G/Zg8DEG9uLXqtdFCHCg2flx+isgAq2RsryY j6umlrh8llfyaEeZ7VfN8BoTaCStJkrdGd4cE5KOGFcSG+c+JP7J59dI8JsYsLgJM/8H 31CA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Fyrl4aN8; 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 s69-20020a632c48000000b004acd11feb3csi13313428pgs.607.2023.03.01.11.12.48; Wed, 01 Mar 2023 11:13:19 -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=Fyrl4aN8; 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 S229676AbjCATFK (ORCPT <rfc822;david.simonyants@gmail.com> + 99 others); Wed, 1 Mar 2023 14:05:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229656AbjCATFD (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 1 Mar 2023 14:05:03 -0500 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DAFF04608F for <linux-kernel@vger.kernel.org>; Wed, 1 Mar 2023 11:05:01 -0800 (PST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-536a545bfbaso291491417b3.20 for <linux-kernel@vger.kernel.org>; Wed, 01 Mar 2023 11:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1677697501; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=eZZzZE8GpdNY+MwogNnFVaUs2b/RvHe7OTvEU8aJPfc=; b=Fyrl4aN8thLa08lvSwfnz3pS77dLDE/JPDoL0n+GfSBVkEYmU/na7n6N3awmHGcBsx fg4YM6nkuIRNWndpa/Vvh28BBbpGpJRQu2vsHAWiO6a5ZOUjmcMA7LOEEPP8t186icRE TTzl2f0lYKQ2gEv3faqd7R7sHmLmFHvz7aRO6WVgfOeUssnPkNyUgEAinVLSyUArDjIp kbm/6C3MBv1I4BXWlD3jhzvuaIkNNoC3TdQPTPCNNYNwWctyfsetJwP6v0E+I8n/tQPA F1L2rtHP4dGjfzEUvNlYgeld/2PRYT7D9g8oV1r1Tb8v8B8+31LZevINjOdzhGWMe5yh P0iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677697501; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=eZZzZE8GpdNY+MwogNnFVaUs2b/RvHe7OTvEU8aJPfc=; b=WZUEvirwD7UCbnGijsQ8TGdrO1nS5k4gOwPGR0jA+eRSnzpvQbzBOgwpNAxpiStSo+ o9k1q6GfX7k9o3qpGOcxirKcl1zaqvVfwIil/zbu+BSXR2cwMBwVp48t/bsK7lO5+zUz sfE9/6yKsZH0k2tmVMrGojzLqXLWROoupy7+XcBjFJtyJJJvgJO6wwpQP/Whau7j6GNR ILEEMH4qCRYTFrAvsTHlW/Tyc6qH1/HU+y172rTjWlpH3nuzUegsqE+UkfTkO0uLRltK Lj/NIQDHGJnnwiWyRbhXt09KqB7iuCaqTKu2UIP+zWP3qYdXr1BjcwU+0cUKPUP+YUBJ DH5w== X-Gm-Message-State: AO0yUKWVAxaR63KmU39rbt1nL/59qpDHHvR3kQq/MppIj1xJazjEZ576 0EwQ43wmicX8ES+mTAQHrsdMUHGI19U= X-Received: from surenb-desktop.mtv.corp.google.com ([2620:15c:211:200:3c40:eeb3:7c3a:807e]) (user=surenb job=sendgmr) by 2002:a0d:c506:0:b0:533:b8f6:828e with SMTP id h6-20020a0dc506000000b00533b8f6828emr19ywd.411.1677697500632; Wed, 01 Mar 2023 11:05:00 -0800 (PST) Date: Wed, 1 Mar 2023 11:04:57 -0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.40.0.rc0.216.gc4246ad0f0-goog Message-ID: <20230301190457.1498985-1-surenb@google.com> Subject: [PATCH 1/1] mm/nommu: remove unnecessary VMA locking 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, paulmck@kernel.org, mingo@redhat.com, will@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, chriscli@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, rppt@kernel.org, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, leewalsh@google.com, posk@google.com, michalechner92@googlemail.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, Suren Baghdasaryan <surenb@google.com>, Hyeonggon Yoo <42.hyeyoo@gmail.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?1759193857721377149?= X-GMAIL-MSGID: =?utf-8?q?1759193857721377149?= |
Series |
[1/1] mm/nommu: remove unnecessary VMA locking
|
|
Commit Message
Suren Baghdasaryan
March 1, 2023, 7:04 p.m. UTC
Since CONFIG_PER_VMA_LOCK depends on CONFIG_MMU, the changes in nommu
are not needed. Remove them.
Fixes: bad94decd6a4 ("mm: write-lock VMAs before removing them from VMA tree")
Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Link: https://lore.kernel.org/all/Y%2F8CJQGNuMUTdLwP@localhost/
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
Fix cleanly applies over mm-unstable, SHA in "Fixes" is from that tree.
mm/nommu.c | 5 -----
1 file changed, 5 deletions(-)
Comments
On 01.03.23 20:04, Suren Baghdasaryan wrote: > Since CONFIG_PER_VMA_LOCK depends on CONFIG_MMU, the changes in nommu > are not needed. Remove them. > > Fixes: bad94decd6a4 ("mm: write-lock VMAs before removing them from VMA tree") > Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > Link: https://lore.kernel.org/all/Y%2F8CJQGNuMUTdLwP@localhost/ > Signed-off-by: Suren Baghdasaryan <surenb@google.com> > --- > Fix cleanly applies over mm-unstable, SHA in "Fixes" is from that tree. > > mm/nommu.c | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/mm/nommu.c b/mm/nommu.c > index 2ab162d773e2..57ba243c6a37 100644 > --- a/mm/nommu.c > +++ b/mm/nommu.c > @@ -588,7 +588,6 @@ static int delete_vma_from_mm(struct vm_area_struct *vma) > current->pid); > return -ENOMEM; > } > - vma_start_write(vma); > cleanup_vma_from_mm(vma); > > /* remove from the MM's tree and list */ > @@ -1520,10 +1519,6 @@ void exit_mmap(struct mm_struct *mm) > */ > mmap_write_lock(mm); > for_each_vma(vmi, vma) { > - /* > - * No need to lock VMA because this is the only mm user and no > - * page fault handled can race with it. > - */ > cleanup_vma_from_mm(vma); > delete_vma(mm, vma); > cond_resched(); So, i assume this should be squashed. Reviewed-by: David Hildenbrand <david@redhat.com> Just a general comment: usually, if review of the original series is still going on, it makes a lot more sense to raise such things in the original series so the author can fixup while things are still in mm-unstable. Once the series is in mm-stable, it's a different story. In that case, it is usually good to have the mail subjects be something like "[PATCH mm-stable 1/1] ...".
On Thu, Mar 2, 2023 at 1:41 AM David Hildenbrand <david@redhat.com> wrote: > > On 01.03.23 20:04, Suren Baghdasaryan wrote: > > Since CONFIG_PER_VMA_LOCK depends on CONFIG_MMU, the changes in nommu > > are not needed. Remove them. > > > > Fixes: bad94decd6a4 ("mm: write-lock VMAs before removing them from VMA tree") > > Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > Link: https://lore.kernel.org/all/Y%2F8CJQGNuMUTdLwP@localhost/ > > Signed-off-by: Suren Baghdasaryan <surenb@google.com> > > --- > > Fix cleanly applies over mm-unstable, SHA in "Fixes" is from that tree. > > > > mm/nommu.c | 5 ----- > > 1 file changed, 5 deletions(-) > > > > diff --git a/mm/nommu.c b/mm/nommu.c > > index 2ab162d773e2..57ba243c6a37 100644 > > --- a/mm/nommu.c > > +++ b/mm/nommu.c > > @@ -588,7 +588,6 @@ static int delete_vma_from_mm(struct vm_area_struct *vma) > > current->pid); > > return -ENOMEM; > > } > > - vma_start_write(vma); > > cleanup_vma_from_mm(vma); > > > > /* remove from the MM's tree and list */ > > @@ -1520,10 +1519,6 @@ void exit_mmap(struct mm_struct *mm) > > */ > > mmap_write_lock(mm); > > for_each_vma(vmi, vma) { > > - /* > > - * No need to lock VMA because this is the only mm user and no > > - * page fault handled can race with it. > > - */ > > cleanup_vma_from_mm(vma); > > delete_vma(mm, vma); > > cond_resched(); > > So, i assume this should be squashed. Yes, that would be best. > > Reviewed-by: David Hildenbrand <david@redhat.com> Thanks1 > > > Just a general comment: usually, if review of the original series is > still going on, it makes a lot more sense to raise such things in the > original series so the author can fixup while things are still in > mm-unstable. Once the series is in mm-stable, it's a different story. In > that case, it is usually good to have the mail subjects be something > like "[PATCH mm-stable 1/1] ...". Ok... For my education, do you mean the title of this patch should somehow reflect that it should be folded into the original patch? Just trying to understand the actionable item here. How would you change this patch when posting for mm-unstable and for mm-stable? Thanks, Suren. > > -- > Thanks, > > David / dhildenb >
>> >> Just a general comment: usually, if review of the original series is >> still going on, it makes a lot more sense to raise such things in the >> original series so the author can fixup while things are still in >> mm-unstable. Once the series is in mm-stable, it's a different story. In >> that case, it is usually good to have the mail subjects be something >> like "[PATCH mm-stable 1/1] ...". > > Ok... For my education, do you mean the title of this patch should > somehow reflect that it should be folded into the original patch? Just > trying to understand the actionable item here. How would you change > this patch when posting for mm-unstable and for mm-stable? For patches that fixup something in mm-stable (stable commit ID but not yet master -> we cannot squash anymore so we need separate commits), it's good to include "mm-stable". The main difference to patches that target master is that by indicating "mm-stable", everyone knows that this is not broken in some upstream/production kernel. For patches that fixup something that is in mm-unstable (no stable commit ID -> still under review and fixup easily possible), IMHO we distinguish between two cases: (1) You fixup your own patches: simply send the fixup as reply to the original patch. Andrew will pick it up and squash it before including it in mm-stable. Sometimes a complete resend of a series makes sense instead. (2) You fixup patches from someone else: simply raise it as a review comment in reply to the original patch. It might make sense to send a patch, but usually you just raise the issue to the patch author as a review comment and the author will address that. Again, Andrew will pick it up and squash it before moving it to mm-stable. That way, it's clearer when stumbling over patches on the mailing list if they fix a real issue in upstream, fix a issue in soon-to-be-upstream, or are simply part of a WIP series that is still under review.
On Fri, Mar 3, 2023 at 1:05 AM David Hildenbrand <david@redhat.com> wrote: > > >> > >> Just a general comment: usually, if review of the original series is > >> still going on, it makes a lot more sense to raise such things in the > >> original series so the author can fixup while things are still in > >> mm-unstable. Once the series is in mm-stable, it's a different story. In > >> that case, it is usually good to have the mail subjects be something > >> like "[PATCH mm-stable 1/1] ...". > > > > Ok... For my education, do you mean the title of this patch should > > somehow reflect that it should be folded into the original patch? Just > > trying to understand the actionable item here. How would you change > > this patch when posting for mm-unstable and for mm-stable? > > For patches that fixup something in mm-stable (stable commit ID but not > yet master -> we cannot squash anymore so we need separate commits), > it's good to include "mm-stable". The main difference to patches that > target master is that by indicating "mm-stable", everyone knows that > this is not broken in some upstream/production kernel. > > > For patches that fixup something that is in mm-unstable (no stable > commit ID -> still under review and fixup easily possible), IMHO we > distinguish between two cases: > > (1) You fixup your own patches: simply send the fixup as reply to the > original patch. Andrew will pick it up and squash it before including it > in mm-stable. Sometimes a complete resend of a series makes sense instead. > > (2) You fixup patches from someone else: simply raise it as a review > comment in reply to the original patch. It might make sense to send a > patch, but usually you just raise the issue to the patch author as a > review comment and the author will address that. Again, Andrew will pick > it up and squash it before moving it to mm-stable. > > > That way, it's clearer when stumbling over patches on the mailing list > if they fix a real issue in upstream, fix a issue in > soon-to-be-upstream, or are simply part of a WIP series that is still > under review. Thanks for the detailed explanation, David. I'll post fixups to mm-unstable patches by replying to the original ones from now on. Interestingly enough, I have another fix today (internal syzcaller found a potential deadlock) which might be interesting enough to be in a separate patch. So, I'll post it as a separate patch and we can discuss whether it should be squashed or kept apart. Thanks, Suren. > > -- > Thanks, > > David / dhildenb >
diff --git a/mm/nommu.c b/mm/nommu.c index 2ab162d773e2..57ba243c6a37 100644 --- a/mm/nommu.c +++ b/mm/nommu.c @@ -588,7 +588,6 @@ static int delete_vma_from_mm(struct vm_area_struct *vma) current->pid); return -ENOMEM; } - vma_start_write(vma); cleanup_vma_from_mm(vma); /* remove from the MM's tree and list */ @@ -1520,10 +1519,6 @@ void exit_mmap(struct mm_struct *mm) */ mmap_write_lock(mm); for_each_vma(vmi, vma) { - /* - * No need to lock VMA because this is the only mm user and no - * page fault handled can race with it. - */ cleanup_vma_from_mm(vma); delete_vma(mm, vma); cond_resched();