All of lore.kernel.org
 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 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.