Message ID | 20230301022720.1380780-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 v21csp3385137wrd; Tue, 28 Feb 2023 18:36:17 -0800 (PST) X-Google-Smtp-Source: AK7set+FIxicNjFFhWZlwNRyHGRFKa0QBBKolPsZS+0YTOOebHqrEAFYwORkbAEuvhLyrdIMxjyp X-Received: by 2002:a17:906:2348:b0:8e5:c06b:90e9 with SMTP id m8-20020a170906234800b008e5c06b90e9mr4721049eja.50.1677638176957; Tue, 28 Feb 2023 18:36:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677638176; cv=none; d=google.com; s=arc-20160816; b=KTt3w487s6ETVB3jES5Cf2bGgqWSBVh2PUERNWlzFNavcmDZOq0dsaKVU2Fc05ymmV u6CLX5uGZ5tqOIRuegoDqDFkix/GFBQgxeroQ2Q+aKoP7UpsNJlsboapEvMREs2ENqnA tfoQcsI42xx69suS50yUvN6ycPZII5k2+P9En5WP4HCav3G0FlKxuPhxsYEX4VOHCBBx oVClua+lQ6TDQ8aZphCpM1Azt1rhMKToNAHOZr/NNhN7BMLSL1On/7gq1/RgzrpDRMPk YMuk6RPRaGblx6qSSwDAI3fmta1JpgBu1+/Q3Ve1q/z1ZXYi3trgyYjw8uknez2pITut e34Q== 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=d/02ba9pKPs+xaeDNoqwdk3OeXtfhs3eb+vbTt5q+ds=; b=UbW9AcWuBmSrym78cQKwY/GMhzLhsG4ggZAWcOc51G70xAqmRij5OcYYBoLG45isqK CZCqFcDQYaZ+fIiVN/fKql5ENRhqhMkPIKaHnud07bs0zvXLfriQ9n6UVemovZd3MNj8 y3IuooOgvf2ArioSNuvuQ8MCmCYRJsdWhD9MznmFrAvRJKSwQsivQKLNV20HJZT4k1W7 3pR6LfnMFeIfXnU5gdNa2xULqSRy3eN9mBDZUPAo68rMiOerv/vSrZOhikgDJ6bBFXkj gkhh9v/kbRLgt8wydo9toYAQDyZfoHnbF5Vya0lTsKZYKr98fOl8v+Q6Nls4IGbZkPvP Kk7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=jwkVCM8M; 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 m8-20020a1709060d8800b008b19eb2bcc8si15260788eji.600.2023.02.28.18.35.54; Tue, 28 Feb 2023 18:36:16 -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=jwkVCM8M; 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 S229735AbjCAC11 (ORCPT <rfc822;aaron.seo0120@gmail.com> + 99 others); Tue, 28 Feb 2023 21:27:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229617AbjCAC1Z (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 28 Feb 2023 21:27:25 -0500 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 026A5136DE for <linux-kernel@vger.kernel.org>; Tue, 28 Feb 2023 18:27:25 -0800 (PST) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-536bbaeceeaso251642447b3.11 for <linux-kernel@vger.kernel.org>; Tue, 28 Feb 2023 18:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1677637644; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=d/02ba9pKPs+xaeDNoqwdk3OeXtfhs3eb+vbTt5q+ds=; b=jwkVCM8M/VdQLhfCkuQxzR9SFY68aOcPkmEc06SJ6jbXq0SL8vhpoeNFFcc2FIMX4Z qOAOI7yp7551oLwvyh9mgMAkw383CXCX5b/h08MQxyDTWLFQM302VK4PCxZW4njJU5wA w8EcBp5F7o/S81X59PWPM2wdZuE0ddMRfvLTZfdeoGxlABs9nXf5/tfjdeYbhTyrLwWT e+FKJlhxrRgP+4+FF7t+gW+oCtxdSoeGJUiUlZqGApiO7FNDs2PJNRAhZDwX5gfdv5E5 1eq6ilJ6KGu4P83kvjayRhSH9oLzyJQNHlvbOeaMFbtv/Mp7aqikHM/ZQ07xCIiTbr5t l13g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677637644; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=d/02ba9pKPs+xaeDNoqwdk3OeXtfhs3eb+vbTt5q+ds=; b=mgDo75/zF6I62CW6ecIa9lGI1UZ45ifgAPCcBYYTBnB/efq0h1Qc8XVxVprFgnmqTO yVRmhTNqmknne7yRSWvi+pWb/gd8Jdy/mFLIS7YYgUjI3BQ69eex0wk8FnAJXciTwwg1 ShEz7EOhokRBDkErCmjh8LBqRne/SiznvYirBZ5XCQiTYFmg8Z/hkzystZP0z1Sbh6I1 2/d8kNQX/RtJmhJm6pXIl9jGWD8aAB8Y2hGHplHPNgyUrFxARgDnIdiUaCbPC7jTWfCA E9wcPmDXrn73c2JirAYwulkG8a9IuUNNNdR1a7HnU+Z+alAzOFEcYvW5qkxnLrZIdNUj xx7Q== X-Gm-Message-State: AO0yUKUH7SkxdD6hwUpU4dJy5DUsSP0laHZPJs4ODd78xXS4an5Wwlvx 2tCM4Ffws8MV9bj6pVO0qisu/OMfbCA= X-Received: from surenb-desktop.mtv.corp.google.com ([2620:15c:211:200:612b:820a:2225:ad82]) (user=surenb job=sendgmr) by 2002:a05:6902:50e:b0:967:f8b2:7a42 with SMTP id x14-20020a056902050e00b00967f8b27a42mr2156872ybs.7.1677637644274; Tue, 28 Feb 2023 18:27:24 -0800 (PST) Date: Tue, 28 Feb 2023 18:27:19 -0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.39.2.722.g9855ee24e9-goog Message-ID: <20230301022720.1380780-1-surenb@google.com> Subject: [PATCH 1/2] mm/mmap: remove unnecessary vp->vma check in vma_prepare From: Suren Baghdasaryan <surenb@google.com> To: akpm@linux-foundation.org Cc: sfr@canb.auug.org.au, error27@gmail.com, willy@infradead.org, david@redhat.com, Liam.Howlett@oracle.com, jgg@ziepe.ca, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, mathieu.desnoyers@efficios.com, pasha.tatashin@soleen.com, laurent.dufour@fr.ibm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, surenb@google.com, kernel test robot <lkp@intel.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?1759131128978866291?= X-GMAIL-MSGID: =?utf-8?q?1759131128978866291?= |
Series |
[1/2] mm/mmap: remove unnecessary vp->vma check in vma_prepare
|
|
Commit Message
Suren Baghdasaryan
March 1, 2023, 2:27 a.m. UTC
vp->vma in vma_prepare() is always non-NULL, therefore checking it is
not necessary. Remove the extra check.
Fixes: e8f071350ea5 ("mm/mmap: write-lock VMAs in vma_prepare before modifying them")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Link: https://lore.kernel.org/r/202302281802.J93Nma7q-lkp@intel.com/
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
Fix cleanly apply over mm-unstable, SHA in "Fixes" is from that tree.
mm/mmap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Comments
On 01.03.23 03:27, Suren Baghdasaryan wrote: > vp->vma in vma_prepare() is always non-NULL, therefore checking it is > not necessary. Remove the extra check. > > Fixes: e8f071350ea5 ("mm/mmap: write-lock VMAs in vma_prepare before modifying them") > Reported-by: kernel test robot <lkp@intel.com> > Reported-by: Dan Carpenter <error27@gmail.com> It would be great to mention that this simply silences a smatch warning. Otherwise, one might be mislead that this commit fixes an actual BUG ;) > Link: https://lore.kernel.org/r/202302281802.J93Nma7q-lkp@intel.com/ > Signed-off-by: Suren Baghdasaryan <surenb@google.com> > --- > Fix cleanly apply over mm-unstable, SHA in "Fixes" is from that tree. > > mm/mmap.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index 0cd3714c2182..0759d53b470c 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -505,8 +505,7 @@ static inline void init_vma_prep(struct vma_prepare *vp, > */ > static inline void vma_prepare(struct vma_prepare *vp) > { > - if (vp->vma) > - vma_start_write(vp->vma); > + vma_start_write(vp->vma); > if (vp->adj_next) > vma_start_write(vp->adj_next); > /* vp->insert is always a newly created VMA, no need for locking */ Yes, that looks correct. Reviewed-by: David Hildenbrand <david@redhat.com>
* Suren Baghdasaryan <surenb@google.com> [230228 21:27]: > vp->vma in vma_prepare() is always non-NULL, therefore checking it is > not necessary. Remove the extra check. > > Fixes: e8f071350ea5 ("mm/mmap: write-lock VMAs in vma_prepare before modifying them") > Reported-by: kernel test robot <lkp@intel.com> > Reported-by: Dan Carpenter <error27@gmail.com> > Link: https://lore.kernel.org/r/202302281802.J93Nma7q-lkp@intel.com/ > Signed-off-by: Suren Baghdasaryan <surenb@google.com> > --- > Fix cleanly apply over mm-unstable, SHA in "Fixes" is from that tree. > > mm/mmap.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index 0cd3714c2182..0759d53b470c 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -505,8 +505,7 @@ static inline void init_vma_prep(struct vma_prepare *vp, > */ > static inline void vma_prepare(struct vma_prepare *vp) > { > - if (vp->vma) > - vma_start_write(vp->vma); > + vma_start_write(vp->vma); Would a WARN_ON_ONCE() be worth it? Maybe not since it will be detected rather quickly once we dereference it below, but it might make it more clear as to what happened? I'm happy either way. Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> > if (vp->adj_next) > vma_start_write(vp->adj_next); > /* vp->insert is always a newly created VMA, no need for locking */ > -- > 2.39.2.722.g9855ee24e9-goog >
On Wed, Mar 1, 2023 at 6:10 AM Liam R. Howlett <Liam.Howlett@oracle.com> wrote: > > * Suren Baghdasaryan <surenb@google.com> [230228 21:27]: > > vp->vma in vma_prepare() is always non-NULL, therefore checking it is > > not necessary. Remove the extra check. > > > > Fixes: e8f071350ea5 ("mm/mmap: write-lock VMAs in vma_prepare before modifying them") > > Reported-by: kernel test robot <lkp@intel.com> > > Reported-by: Dan Carpenter <error27@gmail.com> > > Link: https://lore.kernel.org/r/202302281802.J93Nma7q-lkp@intel.com/ > > Signed-off-by: Suren Baghdasaryan <surenb@google.com> > > --- > > Fix cleanly apply over mm-unstable, SHA in "Fixes" is from that tree. > > > > mm/mmap.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 0cd3714c2182..0759d53b470c 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -505,8 +505,7 @@ static inline void init_vma_prep(struct vma_prepare *vp, > > */ > > static inline void vma_prepare(struct vma_prepare *vp) > > { > > - if (vp->vma) > > - vma_start_write(vp->vma); > > + vma_start_write(vp->vma); > > Would a WARN_ON_ONCE() be worth it? Maybe not since it will be detected > rather quickly once we dereference it below, but it might make it more > clear as to what happened? WARN_ON_ONCE() seems like an overkill to me. It always follows after init_multi_vma_prep()/init_vma_prep() both of which set the VMA. Risk should be minimal here and as you said, misuse is easily discoverable. > > I'm happy either way. > > Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> > > > if (vp->adj_next) > > vma_start_write(vp->adj_next); > > /* vp->insert is always a newly created VMA, no need for locking */ > > -- > > 2.39.2.722.g9855ee24e9-goog > >
diff --git a/mm/mmap.c b/mm/mmap.c index 0cd3714c2182..0759d53b470c 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -505,8 +505,7 @@ static inline void init_vma_prep(struct vma_prepare *vp, */ static inline void vma_prepare(struct vma_prepare *vp) { - if (vp->vma) - vma_start_write(vp->vma); + vma_start_write(vp->vma); if (vp->adj_next) vma_start_write(vp->adj_next); /* vp->insert is always a newly created VMA, no need for locking */