The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Nicolas Schier <nsc@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Julian Braha <julianbraha@gmail.com>,
	rdunlap@infradead.org, masahiroy@kernel.org,
	grahamr@qti.qualcomm.com, nico@fluxnic.net,
	linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH] kconfig: warn on dead default
Date: Tue, 7 Jul 2026 08:06:31 +0200	[thread overview]
Message-ID: <akyXZylHRRgzzpDk@levanger> (raw)
In-Reply-To: <20260707053143.GA1381193@ax162>

On Mon, Jul 06, 2026 at 10:31:43PM -0700, Nathan Chancellor wrote:
> Hi Julian,
> 
> On Sat, Jun 06, 2026 at 03:00:08PM +0100, Julian Braha wrote:
> > The dead default check was originally introduced with kconfirm:
> > https://lore.kernel.org/all/6ec4df6d-1445-48ca-8f54-1d1a83c4716d@gmail.com/
> > 
> > While I'm still working on that tool, it's not yet ready for inclusion
> > into the tree. I am currently waiting for common distro packagers to
> > package the parsing library before submitting the next RFC iteration.
> > 
> > However, the dead default check is more impactful than the other checks:
> > all 4 dead defaults that were detected should not have been dead and could
> > cause misconfiguration bugs. But fortunately, these were just for kunit
> > tests. The 3 patches to fix them have all since been merged:
> > commit aef656a0e6c0 ("powerpc: fix dead default for GUEST_STATE_BUFFER_TEST")
> > commit 30cc5e2ad826 ("s390/Kconfig: Cleanup defaults for selftests")
> > commit df75430515c3 ("drm: fix dead default for DRM_TTM_KUNIT_TEST")
> > 
> > We can actually check for dead defaults while evaluating Kconfig, which
> > should be even more effective at preventing future instances than keeping
> > it in a static checker.
> > 
> > Note that this patch will only trigger a warning when the default values
> > are different, in other words, pure duplicate defaults won't cause a
> > warning, as they are simply redundant.
> > 
> > Signed-off-by: Julian Braha <julianbraha@gmail.com>
> 
> Nicolas pushed this into -next, where it fires several times for me. I
> have not looked at these closely yet, I just wanted to get the report
> out so that more eyes could be on it.
> 
> ARCH=powerpc allmodconfig:
> 
>   arch/powerpc/platforms/Kconfig.cputype:269:warning: default for 'TUNE_CPU' has the same condition as the earlier default at arch/powerpc/platforms/Kconfig.cputype:268
>   arch/powerpc/platforms/Kconfig.cputype:270:warning: default for 'TUNE_CPU' has the same condition as the earlier default at arch/powerpc/platforms/Kconfig.cputype:268
>   lib/Kconfig.debug:1083:warning: default for 'PANIC_TIMEOUT' is unreachable: earlier default at arch/powerpc/Kconfig:350 is unconditional
>   arch/Kconfig:1194:warning: default for 'PGTABLE_LEVELS' is unreachable: earlier default at arch/powerpc/Kconfig:482 is unconditional
> 
> ARCH=s390 allmodconfig:
> 
>   arch/Kconfig:1194:warning: default for 'PGTABLE_LEVELS' is unreachable: earlier default at arch/s390/Kconfig:295 is unconditional
>   lib/Kconfig:372:warning: default for 'HAS_IOMEM' is unreachable: earlier default at arch/s390/Kconfig:760 is unconditional
> 
> When building with clang-23, which supports '-fms-anonymous-struct':
> 
>   init/Kconfig:978:warning: default for 'CC_MS_EXTENSIONS' is unreachable: earlier default at init/Kconfig:977 is unconditional
> 
> I think the init/Kconfig and arch/powerpc/platforms/Kconfig.cputype ones
> are intentional due to how cc-option works but I know those might be
> hard to silence because they are already evaluated by this stage if I
> understand correctly? Not sure about the other ones (apologies if they
> are already known or have fixes).

thanks for the report.  I'll remove the patch from kbuild-for-next
again as there is not obvious immediate solution visible to me right
now.

-- 
Nicolas

  reply	other threads:[~2026-07-07  6:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-06 14:00 [PATCH] kconfig: warn on dead default Julian Braha
2026-06-06 14:23 ` Sam Ravnborg
2026-06-06 15:01   ` Julian Braha
2026-06-06 17:36     ` Sam Ravnborg
2026-07-07  5:31 ` Nathan Chancellor
2026-07-07  6:06   ` Nicolas Schier [this message]
2026-07-07  8:32   ` Julian Braha

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=akyXZylHRRgzzpDk@levanger \
    --to=nsc@kernel.org \
    --cc=grahamr@qti.qualcomm.com \
    --cc=julianbraha@gmail.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=nico@fluxnic.net \
    --cc=rdunlap@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