Message ID | b21f7791b30c54cf8c4d0f489decdc4a47a18963.1679932620.git.jpoimboe@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6358:3404:b0:112:7285:5352 with SMTP id h4csp1525080rwd; Mon, 27 Mar 2023 09:05:37 -0700 (PDT) X-Google-Smtp-Source: AK7set9eoeH0KOHsIyxXnsNhHUEEEo/4QRbhz4nTRk3PBI0mWsL5flY5mL2Fc2zF33ynssveCVoO X-Received: by 2002:a05:6a20:7da6:b0:da:d4eb:9e07 with SMTP id v38-20020a056a207da600b000dad4eb9e07mr11781791pzj.30.1679933005381; Mon, 27 Mar 2023 09:03:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679933005; cv=none; d=google.com; s=arc-20160816; b=SsXTneayCU5e+f6reJ0KGgdPRchAHjC6Pp4plghXI620Hlem/L7ReCBJD4lmFYmqyu WUXv8taFgBNyvJjh5igKfrTUTfAe6DCaeFR6gHwXRU6ttJO23eao0TD+py5WW+tH4AAI MQZpW06mO3Q8hASOiSpYZEVqwl8aFXaebP98Sq9jXjTtzQwhIEEojUBZD3lTRMHksree 6+gaOY5iit1nosRZaNMII81BoLY2h3JzX9bDkxTySfzj58nbMZWSVec0wTDB4XIoJBeR TDXdf06qXlaIfmy6b8nhpAJ9q0YTkm+Zbqu+avk946fkFsDZ3UGIOtT/wlkOsS9Eh7a4 xw6g== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=MlPzgOjIgaQbuDlp+ewku2BEejtll/oMFOYC56z/60s=; b=vcu3kl4raXGlzX+1E/rDBbD9g9sPJq/Qg8Zd6D9CPoZyHVRPrSzD4oHpL6Yo2dmVvm 2ukwn569D8i9XuhIqwU//BCqXs9FActZO1m6mYjNklvhUqJbZus7Pw7L9xcY2ILI0u0J sy8RkoCCv7A69mFmNrxUExTpWW5a+/OGFqXnjGzZIyAkkiAThCuYoPnW0O1uB9Rq2Ox1 bW2GO3oKHoN/87IlXXAjYw7DJcWPj1aaBJExahf51kQPaLMl308GLCD0h+KXagbq2HnT fnCA2G2rENWp90hwGtyONmiYJcY61dOMruvEyhCli6VS3fwaNeqj3YXuQTxcTFwHRDEQ umhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="W9sFA8/7"; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u190-20020a6385c7000000b0050c1054814esi26178587pgd.558.2023.03.27.09.02.59; Mon, 27 Mar 2023 09:03:25 -0700 (PDT) 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=@kernel.org header.s=k20201202 header.b="W9sFA8/7"; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229705AbjC0QBa (ORCPT <rfc822;makky5685@gmail.com> + 99 others); Mon, 27 Mar 2023 12:01:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232781AbjC0QBN (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 27 Mar 2023 12:01:13 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60707659E for <linux-kernel@vger.kernel.org>; Mon, 27 Mar 2023 09:00:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E42F46136A for <linux-kernel@vger.kernel.org>; Mon, 27 Mar 2023 16:00:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8CE07C433A7; Mon, 27 Mar 2023 16:00:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679932856; bh=u69Tg1vdhRZztJGiueD2tMeEsNcJF/AVA/Gcuwho7Uw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=W9sFA8/7euAUx/U00p8kXj+DzpvXxXElLAYtrLNsyf+VP/iQWZsdLAt8Qwu0XaJNH TxHgm5nbvc8dBKA2gh2kcYT7mlqCHwLCKedOZe9VuPZMEr6jqHTKtaNSQtyUTKZMFW +UAHxmvcdxn+WoTt5gbwCHWCRQvZCLBcfnloCe26Km1AgLIGuJLwnmAlm4y9Uo6vH2 WW1C8nAHkmp7NmFuDpTDyk/Q0PLWnU3d3LaTHqDRh3VHM7AMYj0bjf7LR2Zn8JUP/1 n563m3/LNTN0axjJBXYCHiGCF5EM44y9o6oIl1UB6bLeuJV1DQWXm0wdnrvx8A9snu CJg6hplRTKZfg== From: Josh Poimboeuf <jpoimboe@kernel.org> To: x86@kernel.org Cc: linux-kernel@vger.kernel.org, Peter Zijlstra <peterz@infradead.org> Subject: [PATCH 4/5] objtool: Add per-function rate limiting for unreachable warnings Date: Mon, 27 Mar 2023 09:00:47 -0700 Message-Id: <b21f7791b30c54cf8c4d0f489decdc4a47a18963.1679932620.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <cover.1679932620.git.jpoimboe@kernel.org> References: <cover.1679932620.git.jpoimboe@kernel.org> MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable 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?1761537431110830522?= X-GMAIL-MSGID: =?utf-8?q?1761537431110830522?= |
Series |
objtool: warning improvements
|
|
Commit Message
Josh Poimboeuf
March 27, 2023, 4 p.m. UTC
Unreachable instruction warnings are rate limited to once per object
file. That no longer makes sense for vmlinux validation, which might
have other unreachable instructions lurking in other places. Change it
to once per function.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
tools/objtool/check.c | 4 ++++
tools/objtool/include/objtool/elf.h | 1 +
2 files changed, 5 insertions(+)
Comments
On Mon, Mar 27, 2023 at 09:00:47AM -0700, Josh Poimboeuf wrote: > Unreachable instruction warnings are rate limited to once per object > file. That no longer makes sense for vmlinux validation, which might > have other unreachable instructions lurking in other places. Change it > to once per function. Do we want a negative option to disable this? --no-ratelimit or such?
On Mon, 27 Mar 2023, Josh Poimboeuf wrote: > Unreachable instruction warnings are rate limited to once per object > file. That no longer makes sense for vmlinux validation, which might > have other unreachable instructions lurking in other places. Change it > to once per function. > > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> > --- > tools/objtool/check.c | 4 ++++ > tools/objtool/include/objtool/elf.h | 1 + > 2 files changed, 5 insertions(+) > > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > index 73dd091c0075..67a684225702 100644 > --- a/tools/objtool/check.c > +++ b/tools/objtool/check.c > @@ -4557,6 +4557,10 @@ static int validate_reachable_instructions(struct objtool_file *file) > if (insn->visited || ignore_unreachable_insn(file, insn)) > continue; > > + if (insn->sym->warned) > + continue; > + insn->sym->warned = 1; > + Ok > WARN_FUNC("unreachable instruction", insn->sec, insn->offset); > return 1; But we still return here when an unreachable instruction is encountered and warned about. Or maybe I am just misunderstanding the purpose. If not, would it be better to just collect the number of warnings per object as we do elsewhere? warnings++; and then at the end return warnings; Miroslav
On Tue, Mar 28, 2023 at 10:11:05AM +0200, Peter Zijlstra wrote: > On Mon, Mar 27, 2023 at 09:00:47AM -0700, Josh Poimboeuf wrote: > > Unreachable instruction warnings are rate limited to once per object > > file. That no longer makes sense for vmlinux validation, which might > > have other unreachable instructions lurking in other places. Change it > > to once per function. > > Do we want a negative option to disable this? --no-ratelimit or such? Per-function rate-limiting is almost always the right thing, personally I don't envision needing to disable it.
On Tue, Mar 28, 2023 at 01:22:05PM -0700, Josh Poimboeuf wrote: > On Tue, Mar 28, 2023 at 10:11:05AM +0200, Peter Zijlstra wrote: > > On Mon, Mar 27, 2023 at 09:00:47AM -0700, Josh Poimboeuf wrote: > > > Unreachable instruction warnings are rate limited to once per object > > > file. That no longer makes sense for vmlinux validation, which might > > > have other unreachable instructions lurking in other places. Change it > > > to once per function. > > > > Do we want a negative option to disable this? --no-ratelimit or such? > > Per-function rate-limiting is almost always the right thing, personally > I don't envision needing to disable it. Ok, fair enough. I'll let you know if I ever come across the need to disable it :-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 73dd091c0075..67a684225702 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -4557,6 +4557,10 @@ static int validate_reachable_instructions(struct objtool_file *file) if (insn->visited || ignore_unreachable_insn(file, insn)) continue; + if (insn->sym->warned) + continue; + insn->sym->warned = 1; + WARN_FUNC("unreachable instruction", insn->sec, insn->offset); return 1; } diff --git a/tools/objtool/include/objtool/elf.h b/tools/objtool/include/objtool/elf.h index ad0024da262b..a668173a5869 100644 --- a/tools/objtool/include/objtool/elf.h +++ b/tools/objtool/include/objtool/elf.h @@ -61,6 +61,7 @@ struct symbol { u8 return_thunk : 1; u8 fentry : 1; u8 profiling_func : 1; + u8 warned : 1; struct list_head pv_target; struct list_head reloc_list; };