From: Sean Christopherson <seanjc@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Yan Zhao <yan.y.zhao@intel.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 1/2] x86/bug: Add printf() validation to HAVE_ARCH_BUG_FORMAT_ARGS WARNs
Date: Thu, 23 Apr 2026 08:47:58 -0700 [thread overview]
Message-ID: <aeo_Lt7Pyv0f_T3O@google.com> (raw)
In-Reply-To: <bf130cce-f758-4aee-b639-4f3a662de6dd@intel.com>
On Thu, Apr 23, 2026, Dave Hansen wrote:
> On 4/23/26 07:54, Sean Christopherson wrote:
> > Lack of validation is especially problematic for code that is 64-bit-only,
> > as blatant goofs can easily go unnoticed, as they (somewhat ironically)
> > will only be noticed by CONFIG_BUG=n builds.
>
> This took me a minute to piece together.
>
> CONFIG_BUG=n builds use the asm-generic/bug.h implementations which have:
>
> no_printk(format);
>
> and do their own printk validation. Right?
Ya.
> Also, what do you mean about 64-bit-only code?
32-bit x86 doesn't support HAVE_ARCH_BUG_FORMAT_ARGS, and so it too uses generic
implementations that provide printk validation. I.e. the blind spot is code that
is strictly x86-64, because code that builds on other architectures and on 32-bit
x86 will be detected by those other builds, and unlike CONFIG_BUG=n, people and
bots regularly test those configurations.
> I'm also debating if we should stick these in x86/urgent and get them to
> Linus sooner rather than later so folks aren't bitten by this for a
> whole development cycle.
next prev parent reply other threads:[~2026-04-23 15:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 14:54 [PATCH v2 0/2] x86/bug: Add printf() validation to x86's custom WARNs Sean Christopherson
2026-04-23 14:54 ` [PATCH v2 1/2] x86/bug: Add printf() validation to HAVE_ARCH_BUG_FORMAT_ARGS WARNs Sean Christopherson
2026-04-23 15:12 ` Dave Hansen
2026-04-23 15:47 ` Sean Christopherson [this message]
2026-04-23 16:58 ` Dave Hansen
2026-04-27 19:05 ` [tip: x86/misc] " tip-bot2 for Sean Christopherson
2026-04-27 19:55 ` Sean Christopherson
2026-04-23 14:54 ` [PATCH v2 2/2] x86/bug: Put HAVE_ARCH_BUG_FORMAT_ARGS WARN definitions inside __ASSEMBLER__ Sean Christopherson
2026-04-27 19:05 ` [tip: x86/misc] " tip-bot2 for Sean Christopherson
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=aeo_Lt7Pyv0f_T3O@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=yan.y.zhao@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.