> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f3f7cb01d69d..bf8288b3d52b 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -327,6 +327,7 @@ config X86
> select USER_STACKTRACE_SUPPORT
> select HAVE_ARCH_KCSAN if X86_64
> select PROC_PID_ARCH_STATUS if PROC_FS
> + select HAS_SEPARATE_PREEMPT_RESCHED_BITS if X86_64
> select HAVE_ARCH_NODE_DEV_GROUP if X86_SGX
A subsystem pattern flags this as potentially concerning: selecting
HAS_SEPARATE_PREEMPT_RESCHED_BITS with only the X86_64 condition may
bypass the PREEMPT_COUNT dependency.
Looking at the definition in kernel/Kconfig.preempt, the config symbol
HAS_SEPARATE_PREEMPT_RESCHED_BITS explicitly depends on both PREEMPT_COUNT
and 64BIT:
kernel/Kconfig.preempt:
config HAS_SEPARATE_PREEMPT_RESCHED_BITS
bool
depends on PREEMPT_COUNT && 64BIT
PREEMPT_COUNT is not always enabled. It gets selected by PREEMPTION, and
by a few debug configs (CONFIG_DEBUG_PREEMPT, DEBUG_ATOMIC_SLEEP,
PREEMPT_TRACER, etc.), but a standard CONFIG_PREEMPT_NONE=y configuration
without any of those debug options will have PREEMPT_COUNT=n.
In such a configuration, the select statement (gated only by X86_64)
will force HAS_SEPARATE_PREEMPT_RESCHED_BITS=y while its depends on
PREEMPT_COUNT is unmet. This will produce a Kconfig unmet-dependency
warning: "WARNING: unmet direct dependencies detected for
HAS_SEPARATE_PREEMPT_RESCHED_BITS / Depends on [n]: PREEMPT_COUNT &&
64BIT / Selected by [y]: - X86 [=y]".
Sashiko-bot raised this concern in both v2 and v3 of this patch (message
IDs <[email protected]> and
<[email protected]>), escalating it from Low to
Medium severity:
https://lore.kernel.org/all/[email protected]/
Should this select be conditional on PREEMPT_COUNT? For example:
select HAS_SEPARATE_PREEMPT_RESCHED_BITS if X86_64 && PREEMPT_COUNT
[ ... ]
> diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
> index 88c594c6d7fc..35f546a042b1 100644
> --- a/kernel/Kconfig.preempt
> +++ b/kernel/Kconfig.preempt
> @@ -122,6 +122,10 @@ config PREEMPT_RT_NEEDS_BH_LOCK
> config PREEMPT_COUNT
> bool
>
> +config HAS_SEPARATE_PREEMPT_RESCHED_BITS
> + bool
> + depends on PREEMPT_COUNT && 64BIT
> +
This commit fixes a bug but lacks a Fixes: tag. The commit corrects
underflow detection logic in preempt_count_sub() by changing from a signed
comparison to unsigned wraparound detection. The bug was introduced when
commit 7c346d37f86b expanded the preempt_count bit layout by adding 8-bit
HARDIRQ_DISABLE_BITS, increasing total bit usage from 21 to 29 bits.
This expansion highlighted the flaw in the existing signed comparison
underflow check (val > preempt_count()), which doesn't correctly detect
unsigned underflow. The fix properly uses unsigned arithmetic (pc - uval >
pc) to detect wraparound.
Should this include:
Fixes: 7c346d37f86b ("preempt: Introduce HARDIRQ_DISABLE_BITS")
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26998319662
