BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Boqun Feng" <boqun@kernel.org>
Cc: bpf@vger.kernel.org, ojeda@kernel.org
Subject: Re: [PATCH v3 10/13] preempt: Introduce HAS_SEPARATE_PREEMPT_RESCHED_BITS
Date: Fri, 05 Jun 2026 05:59:55 +0000	[thread overview]
Message-ID: <20260605055956.46EC81F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260605054128.5925-11-boqun@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unconditional select of `HAS_SEPARATE_PREEMPT_RESCHED_BITS` violates Kconfig dependency on `PREEMPT_COUNT`.
--

commit 0d37eeeba0d2e4fb4b795207e44eb2cab20db648
Author: Boqun Feng <boqun@kernel.org>

preempt: Introduce HAS_SEPARATE_PREEMPT_RESCHED_BITS

This commit introduces HAS_SEPARATE_PREEMPT_RESCHED_BITS to allow 64-bit 
architectures to maintain NMI nesting bits in the 32-bit preempt count, 
avoiding the need to maintain them outside the same cache line. It also 
enables this feature for x86_64.

Originally-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Boqun Feng <boqun@kernel.org>

> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index fdaef60b46d65..9a35c3a087573 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -329,6 +329,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

[Severity: Medium]
Will selecting HAS_SEPARATE_PREEMPT_RESCHED_BITS unconditionally for X86_64 
cause Kconfig unmet direct dependency warnings if PREEMPT_COUNT is disabled?

Looking at the definition in kernel/Kconfig.preempt, the config symbol 
HAS_SEPARATE_PREEMPT_RESCHED_BITS explicitly depends on PREEMPT_COUNT:

config HAS_SEPARATE_PREEMPT_RESCHED_BITS
    bool
    depends on PREEMPT_COUNT && 64BIT

Because select bypasses depends on, configuring a kernel where PREEMPT_COUNT
is disabled (e.g., PREEMPT_NONE=y with no debug options) might force the 
target symbol to y. Should this select be conditional on PREEMPT_COUNT?

>  	select HAVE_ARCH_NODE_DEV_GROUP		if X86_SGX
>  	select FUNCTION_ALIGNMENT_16B		if X86_64 || X86_ALIGNMENT_16
>  	select FUNCTION_ALIGNMENT_4B

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605054128.5925-1-boqun@kernel.org?part=10

  reply	other threads:[~2026-06-05  5:59 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-05  5:41 [PATCH v3 00/13] Refcounted interrupt disable and SpinLockIrq for rust (Part 1) Boqun Feng
2026-06-05  5:41 ` [PATCH v3 01/13] preempt: Track NMI nesting to separate per-CPU counter Boqun Feng
2026-06-05  5:59   ` sashiko-bot
2026-06-05  5:41 ` [PATCH v3 02/13] preempt: Introduce HARDIRQ_DISABLE_BITS Boqun Feng
2026-06-05  6:01   ` sashiko-bot
2026-06-05  5:41 ` [PATCH v3 03/13] preempt: Introduce __preempt_count_{sub, add}_return() Boqun Feng
2026-06-05  5:59   ` sashiko-bot
2026-06-05  6:30   ` bot+bpf-ci
2026-06-05  6:45     ` Boqun Feng
2026-06-05  5:41 ` [PATCH v3 04/13] openrisc: Include <linux/cpumask.h> in smp.h Boqun Feng
2026-06-05  5:41 ` [PATCH v3 05/13] irq & spin_lock: Add counted interrupt disabling/enabling Boqun Feng
2026-06-05  6:01   ` sashiko-bot
2026-06-05  6:27     ` Boqun Feng
2026-06-05  6:30   ` bot+bpf-ci
2026-06-05  6:40     ` Boqun Feng
2026-06-05  5:41 ` [PATCH v3 06/13] irq: Add KUnit test for refcounted interrupt enable/disable Boqun Feng
2026-06-05  5:53   ` sashiko-bot
2026-06-05  5:41 ` [PATCH v3 07/13] locking: Switch to _irq_{disable,enable}() variants in cleanup guards Boqun Feng
2026-06-05  5:57   ` sashiko-bot
2026-06-05  5:41 ` [PATCH v3 08/13] sched: Remove the unused preempt_offset parameter of __cant_sleep() Boqun Feng
2026-06-05  5:41 ` [PATCH v3 09/13] sched: Avoid signed comparison of preempt_count() in __cant_migrate() Boqun Feng
2026-06-05  5:41 ` [PATCH v3 10/13] preempt: Introduce HAS_SEPARATE_PREEMPT_RESCHED_BITS Boqun Feng
2026-06-05  5:59   ` sashiko-bot [this message]
2026-06-05  6:30   ` bot+bpf-ci
2026-06-05  5:41 ` [PATCH v3 11/13] arm64: sched/preempt: Enable HAS_SEPARATE_PREEMPT_RESCHED_BITS Boqun Feng
2026-06-05  5:41 ` [PATCH v3 12/13] s390/preempt: " Boqun Feng
2026-06-05  5:41 ` [PATCH v3 13/13] irq: Optimize reschedule check in local_interrupt_enable() Boqun Feng
2026-06-05  6:04   ` sashiko-bot

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=20260605055956.46EC81F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=boqun@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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