BPF List
 help / color / mirror / Atom feed
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

  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