Message ID | 20231201145936.5ddfdb50@gandalf.local.home |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp1380093vqy; Fri, 1 Dec 2023 11:59:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IFWRT3CE5FGSyHHVZdJiURCwKX0vrlVo91hSG1ifcHhrdjiCROXNHiT4X1vbYkWSRhBybqF X-Received: by 2002:a17:902:8696:b0:1d0:6ffd:9e2e with SMTP id g22-20020a170902869600b001d06ffd9e2emr38659plo.128.1701460760445; Fri, 01 Dec 2023 11:59:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701460760; cv=none; d=google.com; s=arc-20160816; b=gcyJlcPN3ypBCMs6+38pLfrvf67m4Q5H4CZSFumWrkT9CMPR85Oil/uEwynknxu6gr CNMHcSJapEIjO0B/wJ5ySexn53IkeGy00n3QZhdq7n9UKyxT8PSgvBhir+NLIGFU8L5a lF2PGnNDgvBiEC5phT1jbgr/DWDIZ2c5ltHbWFJFbN8BDZMqlNiHcPazIvZLErLTzY0x JIFno0BcT1oTGzXOeRM+TuUFBpQnzyG6CzndVm8eeyaSUJQ1IFYXtj+3mL1C32KgXNno My1yd7bHXRrKm/wcGhc9KyojEcK4toFcwobIA9VHSw6xwmRMQFer9RONqHN2QkeBYmCL ypwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:subject:cc:to:from:date; bh=rwUpQFXbjYqRHwq4L4PRd+w0zOguEZrN+oy1TiU9DNo=; fh=yaqZu3JbG/uGA6V2iV56TbRNqA0l77H0ikG18l9uibM=; b=j1qnZJwcTZXSM17TnKWluHLWvlPaOkoSwXdfuLiBMvgVPCTiv63t45MxWyQUZI7OfQ ggMQkp+uA+91prUOiks84Y6a9ddXOvkP/ppRmrtS4xgHKYf/h50jX2AqDxYnMkPSksOh xT44eVTBq9Z+DpzfZjTcQl0whM9akgu9eFMuotDOrHpJ+cZ+ZsOa6ZP8D04V+9a/nxUQ F+Dslj84CCTSdguWbtmG/ThZei8YFaSEDqNHtJbZ49hLUCkdCQK8iGZ6NdFgrji1sCOj 4vUvu8Wfs8bxT/CYX9doMbF1878e6fukO5msZ/LqQutdcamJmNPDrdI5du24pBF22YU7 tGmA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id d1-20020a170902cec100b001d014c43a94si4008572plg.517.2023.12.01.11.59.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Dec 2023 11:59:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id AB8108297223; Fri, 1 Dec 2023 11:59:15 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379567AbjLAT7H (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Fri, 1 Dec 2023 14:59:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52054 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379559AbjLAT7G (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 1 Dec 2023 14:59:06 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EEA6AFA for <linux-kernel@vger.kernel.org>; Fri, 1 Dec 2023 11:59:12 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0AAEDC433C9; Fri, 1 Dec 2023 19:59:11 +0000 (UTC) Date: Fri, 1 Dec 2023 14:59:36 -0500 From: Steven Rostedt <rostedt@goodmis.org> To: LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org Cc: David Hildenbrand <david@redhat.com>, Vlastimil Babka <vbabka@suse.cz>, Andrew Morton <akpm@linux-foundation.org> Subject: [PATCH] mm/rmap: Fix misplaced parenthesis of a likely() Message-ID: <20231201145936.5ddfdb50@gandalf.local.home> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Fri, 01 Dec 2023 11:59:15 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784110918177360707 X-GMAIL-MSGID: 1784110918177360707 |
Series |
mm/rmap: Fix misplaced parenthesis of a likely()
|
|
Commit Message
Steven Rostedt
Dec. 1, 2023, 7:59 p.m. UTC
From: Steven Rostedt (Google) <rostedt@goodmis.org> Running my yearly branch profiler to see where likely/unlikely annotation may be added or removed, I discovered this: correct incorrect % Function File Line ------- --------- - -------- ---- ---- 0 457918 100 page_try_dup_anon_rmap rmap.h 264 [..] 458021 0 0 page_try_dup_anon_rmap rmap.h 265 I thought it was interesting that line 264 of rmap.h had a 100% incorrect annotation, but the line directly below it was 100% correct. Looking at the code: if (likely(!is_device_private_page(page) && unlikely(page_needs_cow_for_dma(vma, page)))) It didn't make sense. The "likely()" was around the entire if statement (not just the "!is_device_private_page(page)"), which also included the "unlikely()" portion of that if condition. If the unlikely portion is unlikely to be true, that would make the entire if condition unlikely to be true, so it made no sense at all to say the entire if condition is true. What is more likely to be likely is just the first part of the if statement before the && operation. It's likely to be a misplaced parenthesis. And after making the if condition broken into a likely() && unlikely(), both now appear to be correct! Cc: stable@vger.kernel.org Fixes:fb3d824d1a46c ("mm/rmap: split page_dup_rmap() into page_dup_file_rmap() and page_try_dup_anon_rmap()") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> ---
Comments
On 01.12.23 20:59, Steven Rostedt wrote: > From: Steven Rostedt (Google) <rostedt@goodmis.org> > > Running my yearly branch profiler to see where likely/unlikely annotation > may be added or removed, I discovered this: > > correct incorrect % Function File Line > ------- --------- - -------- ---- ---- > 0 457918 100 page_try_dup_anon_rmap rmap.h 264 > [..] > 458021 0 0 page_try_dup_anon_rmap rmap.h 265 > That looks like a handy tool! > I thought it was interesting that line 264 of rmap.h had a 100% incorrect > annotation, but the line directly below it was 100% correct. Looking at the > code: > > if (likely(!is_device_private_page(page) && > unlikely(page_needs_cow_for_dma(vma, page)))) > > It didn't make sense. The "likely()" was around the entire if statement > (not just the "!is_device_private_page(page)"), which also included the > "unlikely()" portion of that if condition. Yes, that was clearly misplaced. > > If the unlikely portion is unlikely to be true, that would make the entire > if condition unlikely to be true, so it made no sense at all to say the > entire if condition is true. > > What is more likely to be likely is just the first part of the if statement > before the && operation. It's likely to be a misplaced parenthesis. And > after making the if condition broken into a likely() && unlikely(), both > now appear to be correct! > Reviewed-by: David Hildenbrand <david@redhat.com> But > Cc: stable@vger.kernel.org stable, really? Why? > Fixes:fb3d824d1a46c ("mm/rmap: split page_dup_rmap() into page_dup_file_rmap() and page_try_dup_anon_rmap()") and does it even fix a real bug?
On Fri, 1 Dec 2023 21:06:22 +0100 David Hildenbrand <david@redhat.com> wrote: > But > > > Cc: stable@vger.kernel.org > > stable, really? Why? > > > Fixes:fb3d824d1a46c ("mm/rmap: split page_dup_rmap() into page_dup_file_rmap() and page_try_dup_anon_rmap()") > > and does it even fix a real bug? As a performance person, who measures likely and unlikely results (the ftrace ring buffer was sped up by over 50% with strategically placed likely/unlikely annotation). I find this to be a real bug, and something I would want backported to the kernels we maintain in ChromeOS (which uses upstream stable kernels). -- Steve
On 01.12.23 21:15, Steven Rostedt wrote: > On Fri, 1 Dec 2023 21:06:22 +0100 > David Hildenbrand <david@redhat.com> wrote: > >> But >> >>> Cc: stable@vger.kernel.org >> >> stable, really? Why? >> >>> Fixes:fb3d824d1a46c ("mm/rmap: split page_dup_rmap() into page_dup_file_rmap() and page_try_dup_anon_rmap()") >> >> and does it even fix a real bug? > > As a performance person, who measures likely and unlikely results (the > ftrace ring buffer was sped up by over 50% with strategically placed > likely/unlikely annotation). I find this to be a real bug, and something I > would want backported to the kernels we maintain in ChromeOS (which uses > upstream stable kernels). Okay, I don't care that much about a "Fixes" annotation. But I am *pretty* sure that this is not stable material, looking once again at the stable rules. Anyhow, thanks for catching this!
On 12/1/23 20:59, Steven Rostedt wrote: > From: Steven Rostedt (Google) <rostedt@goodmis.org> > > Running my yearly branch profiler to see where likely/unlikely annotation > may be added or removed, I discovered this: > > correct incorrect % Function File Line > ------- --------- - -------- ---- ---- > 0 457918 100 page_try_dup_anon_rmap rmap.h 264 > [..] > 458021 0 0 page_try_dup_anon_rmap rmap.h 265 > > I thought it was interesting that line 264 of rmap.h had a 100% incorrect > annotation, but the line directly below it was 100% correct. Looking at the > code: > > if (likely(!is_device_private_page(page) && > unlikely(page_needs_cow_for_dma(vma, page)))) > > It didn't make sense. The "likely()" was around the entire if statement > (not just the "!is_device_private_page(page)"), which also included the > "unlikely()" portion of that if condition. > > If the unlikely portion is unlikely to be true, that would make the entire > if condition unlikely to be true, so it made no sense at all to say the > entire if condition is true. > > What is more likely to be likely is just the first part of the if statement > before the && operation. It's likely to be a misplaced parenthesis. And > after making the if condition broken into a likely() && unlikely(), both > now appear to be correct! > > Cc: stable@vger.kernel.org > Fixes:fb3d824d1a46c ("mm/rmap: split page_dup_rmap() into page_dup_file_rmap() and page_try_dup_anon_rmap()") > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by: Vlastimil Babka <vbabka@suse.cz> Pragmatically speaking, stable maintainers haven't been following the stable rules for a long time, and a commit with Fixes and without Cc: stable is often backported on the assumption people forget Cc: stable, and "Fixes:" implies there's a bug to fix, and it's good to have bugs fixed in stable... We have (repeatedly...) had mm extempted from this and Cc: stable is required, which is good. So if Steven thinks there are reasons to backport, then I'd rather let him keep the Cc: stable, instead of this later becoming an argument to question the mm extemption again :) > --- > diff --git a/include/linux/rmap.h b/include/linux/rmap.h > index b26fe858fd44..3c2fc291b071 100644 > --- a/include/linux/rmap.h > +++ b/include/linux/rmap.h > @@ -261,8 +261,8 @@ static inline int page_try_dup_anon_rmap(struct page *page, bool compound, > * guarantee the pinned page won't be randomly replaced in the > * future on write faults. > */ > - if (likely(!is_device_private_page(page) && > - unlikely(page_needs_cow_for_dma(vma, page)))) > + if (likely(!is_device_private_page(page)) && > + unlikely(page_needs_cow_for_dma(vma, page))) > return -EBUSY; > > ClearPageAnonExclusive(page);
diff --git a/include/linux/rmap.h b/include/linux/rmap.h index b26fe858fd44..3c2fc291b071 100644 --- a/include/linux/rmap.h +++ b/include/linux/rmap.h @@ -261,8 +261,8 @@ static inline int page_try_dup_anon_rmap(struct page *page, bool compound, * guarantee the pinned page won't be randomly replaced in the * future on write faults. */ - if (likely(!is_device_private_page(page) && - unlikely(page_needs_cow_for_dma(vma, page)))) + if (likely(!is_device_private_page(page)) && + unlikely(page_needs_cow_for_dma(vma, page))) return -EBUSY; ClearPageAnonExclusive(page);