public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Brendan Jackman <jackmanb@google.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Nicolas Schier <nicolas@fjasle.eu>,
	linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings
Date: Thu, 6 Feb 2025 10:10:36 -0700	[thread overview]
Message-ID: <20250206171036.GF180182@ax162> (raw)
In-Reply-To: <CA+i-1C1A_0nkY6G+W3n=dYqEJHZGuEwNXK=xrWNwDh7561x_9A@mail.gmail.com>

On Thu, Feb 06, 2025 at 04:05:01PM +0100, Brendan Jackman wrote:
> OK, it would be interesting to spend a couple of hours staring at
> these errors and see if I can get a feel for the overal picture..
> 
> Also, now that I think about it I'm a bit embarrassed I didn't try
> building allmodconfig before sending this series (maybe I had
> forgotten it exists?)! Sorry about that :)
> 
> On Fri, 31 Jan 2025 at 21:49, Nathan Chancellor <nathan@kernel.org> wrote:
> > > But I can also envisage a world where that creates exactly as much
> > > work for you, just introducing Kconfig hackery for no reason!
> >
> > Such is the nature of such changes. It is not that big of a deal for us
> > to work around in the short term but it would still need to be addressed
> > pretty quickly at that point.
> 
> I can't quite parse what you're getting at here - is this an opinion
> about the idea to depend on !COMPILE_TEST, and if so are you in favour
> of it?

Sorry, that was more of a comment around having to disable that
configuration for builds such as allmodconfig if necessary to keep our
builds green. We can do it but that is not a long term solution because
we are not the only ones building allmodconfig with clang and we cannot
just tell everyone to disable it.

> My thinking is that if it defaults n and isn't in allmodconfig, the
> only people who will turn it on are those who actively care about
> clean objtool for their build. Which.. isn't really what we want long
> term, but it's better than not having the option at all and is already
> a step in the direction of something that can act as a "ratchet".

Right, I think gating on '!COMPILE_TEST' would not be a terrible way to
introduce it. We would definitely want to remove that dependency as
soon as possible because we want compile testers to be qble to find
these problems and have them be noticeable but it should make the
introduction of CONFIG_OBJTOOL_WERROR less disruptive.

> If not, I'll go ahead with the OBJTOOL_FLAGS thing. (Which is still a
> nice step in that direction).

This may still be worth doing because with the aforementioned
dependency, it would make it difficult to test with --Werror for
COMPILE_TEST configurations.  Maybe Josh or Peter have other opinions
though.

Cheers,
Nathan

  reply	other threads:[~2025-02-06 17:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-13 14:05 [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings Brendan Jackman
2025-01-13 14:05 ` [PATCH v3 1/2] objtool: Add --Werror Brendan Jackman
2025-01-14 17:24   ` Nathan Chancellor
2025-01-14 18:17     ` Josh Poimboeuf
2025-01-13 14:05 ` [PATCH v3 2/2] kbuild: Add option to fail build on vmlinux objtool issues Brendan Jackman
2025-01-14  0:14 ` [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings Josh Poimboeuf
2025-01-30 15:55   ` Brendan Jackman
2025-01-30 18:30     ` Nathan Chancellor
2025-01-31 10:44       ` Brendan Jackman
2025-01-31 20:49         ` Nathan Chancellor
2025-02-06 15:05           ` Brendan Jackman
2025-02-06 17:10             ` Nathan Chancellor [this message]
2025-02-07  2:51               ` Josh Poimboeuf
2025-02-07 10:16                 ` Brendan Jackman
2025-02-07 21:41                 ` Nathan Chancellor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250206171036.GF180182@ax162 \
    --to=nathan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=jackmanb@google.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=nicolas@fjasle.eu \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox