From: sashiko-bot@kernel.org
To: "Boqun Feng" <boqun@kernel.org>
Cc: ojeda@kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH v3 02/13] preempt: Introduce HARDIRQ_DISABLE_BITS
Date: Fri, 05 Jun 2026 06:01:08 +0000 [thread overview]
Message-ID: <20260605060109.3B8741F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260605054128.5925-3-boqun@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] NMI nesting inside a hardirq causes `HARDIRQ` count to overflow into `NMI` bits, leading to permanent `preempt_count` corruption and a kernel panic.
--
commit 81acab4bc4267e8b9061bcb43c1763c01ce614f2
Author: Boqun Feng <boqun@kernel.org>
preempt: Introduce HARDIRQ_DISABLE_BITS
This commit changes the preempt_count() layout to contain an 8-bit
HARDIRQ_DISABLE count to track interrupt disabling nested levels. This
supports preempt_disable()-like interrupt disabling.
Link: https://patch.msgid.link/20260121223933.1568682-2-lyude@redhat.com
> diff --git a/include/linux/preempt.h b/include/linux/preempt.h
> index 586f966883255..e2d3079d3f5f1 100644
> --- a/include/linux/preempt.h
> +++ b/include/linux/preempt.h
[ ... ]
> @@ -31,29 +32,34 @@
> *
> * PREEMPT_MASK: 0x000000ff
> * SOFTIRQ_MASK: 0x0000ff00
> - * HARDIRQ_MASK: 0x000f0000
> - * NMI_MASK: 0x00100000
> + * HARDIRQ_DISABLE_MASK: 0x00ff0000
> + * HARDIRQ_MASK: 0x0f000000
> + * NMI_MASK: 0x10000000
> * PREEMPT_NEED_RESCHED: 0x80000000
> */
> #define PREEMPT_BITS 8
> #define SOFTIRQ_BITS 8
> +#define HARDIRQ_DISABLE_BITS 8
> #define HARDIRQ_BITS 4
[Severity: High]
This is a pre-existing issue, but does keeping HARDIRQ_BITS at 4 risk a
structural overflow into the NMI bits during deep NMI nesting?
Looking at __preempt_count_nmi_enter() in include/linux/hardirq.h, it adds
HARDIRQ_OFFSET to preempt_count on every NMI, and explicitly permits up to
15 nested NMIs:
include/linux/hardirq.h:__preempt_count_nmi_enter() {
__preempt_count_add(HARDIRQ_OFFSET);
/* Maximum NMI nesting is 15. */
BUG_ON(__this_cpu_read(nmi_nesting) >= 15);
...
}
If 15 NMIs nest while the CPU is already inside a hardirq (where the HARDIRQ
count is 1), the total count reaches 16.
Since HARDIRQ_BITS is 4, would a value of 16 overflow the 4-bit field into the
adjacent NMI field? It appears this could corrupt preempt_count and eventually
clear the NMI flags prematurely during exit, leading to a kernel panic.
> #define NMI_BITS 1
>
> #define PREEMPT_SHIFT 0
> #define SOFTIRQ_SHIFT (PREEMPT_SHIFT + PREEMPT_BITS)
> -#define HARDIRQ_SHIFT (SOFTIRQ_SHIFT + SOFTIRQ_BITS)
> +#define HARDIRQ_DISABLE_SHIFT (SOFTIRQ_SHIFT + SOFTIRQ_BITS)
> +#define HARDIRQ_SHIFT (HARDIRQ_DISABLE_SHIFT + HARDIRQ_DISABLE_BITS)
> #define NMI_SHIFT (HARDIRQ_SHIFT + HARDIRQ_BITS)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260605054128.5925-1-boqun@kernel.org?part=2
next prev parent reply other threads:[~2026-06-05 6:01 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 [this message]
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
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=20260605060109.3B8741F00893@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