From: sashiko-bot@kernel.org
To: "Boqun Feng" <boqun@kernel.org>
Cc: bpf@vger.kernel.org, ojeda@kernel.org
Subject: Re: [PATCH v2 06/12] irq: Add KUnit test for refcounted interrupt enable/disable
Date: Tue, 26 May 2026 18:18:25 +0000 [thread overview]
Message-ID: <20260526181826.58EAD1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260526152148.30514-7-boqun@kernel.org>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] KUnit test assertions are executed while hardware interrupts are disabled, causing a `GFP_KERNEL` allocation and kernel BUG if a test expectation fails.
- [High] The test suite lacks robust teardown and initialization to protect the kernel from leaking disabled interrupt states.
- [Low] The KUnit test is unconditionally compiled when CONFIG_KUNIT is enabled, bypassing subsystem-specific test configs.
- [Low] Missing closing parenthesis in a code comment.
--
commit ad24a2af47c3509344d4c410cf8820cb3d8e2b06
Author: Lyude Paul <lyude@redhat.com>
irq: Add KUnit test for refcounted interrupt enable/disable
Adds a KUnit test suite to verify the refcounted interrupt enable and
disable functionality.
Link: https://patch.msgid.link/20260121223933.1568682-7-lyude@redhat.com
> diff --git a/kernel/irq/Makefile b/kernel/irq/Makefile
> index 86a2e5ae08f9a..44c4d6fc502ac 100644
> --- a/kernel/irq/Makefile
> +++ b/kernel/irq/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_SMP) += affinity.o
> obj-$(CONFIG_GENERIC_IRQ_DEBUGFS) += debugfs.o
> obj-$(CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR) += matrix.o
> obj-$(CONFIG_IRQ_KUNIT_TEST) += irq_test.o
> +obj-$(CONFIG_KUNIT) += refcount_interrupt_test.o
[Severity: Low]
Should this test be guarded by a subsystem-specific configuration option like
CONFIG_IRQ_KUNIT_TEST instead of CONFIG_KUNIT?
Building it unconditionally when CONFIG_KUNIT is enabled means the test
will automatically execute on any kernel with KUnit globally enabled, which
might bypass subsystem test configs and increase test execution times.
> diff --git a/kernel/irq/refcount_interrupt_test.c b/kernel/irq/refcount_interrupt_test.c
> new file mode 100644
> index 0000000000000..b4f224595f261
> --- /dev/null
> +++ b/kernel/irq/refcount_interrupt_test.c
> @@ -0,0 +1,109 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit test for refcounted interrupt enable/disables.
> + */
> +
> +#include <kunit/test.h>
> +#include <linux/interrupt_rc.h>
> +
> +#define TEST_IRQ_ON() KUNIT_EXPECT_FALSE(test, irqs_disabled())
> +#define TEST_IRQ_OFF() KUNIT_EXPECT_TRUE(test, irqs_disabled())
> +
> +/* ===== Test cases ===== */
> +static void test_single_irq_change(struct kunit *test)
> +{
> + local_interrupt_disable();
> + TEST_IRQ_OFF();
[Severity: High]
Could this trigger a sleeping in atomic context BUG if the test expectation
fails?
If TEST_IRQ_OFF() or TEST_IRQ_ON() fails, KUnit invokes kunit_fail(), which
uses GFP_KERNEL to allocate memory for the failure message. Since GFP_KERNEL
implies __GFP_DIRECT_RECLAIM, doing this while hardware interrupts are
disabled violates atomic context rules.
Would it be safer to save the interrupt state to a local variable inside the
atomic section and evaluate the KUnit assertion after interrupts are safely
re-enabled?
[ ... ]
> +static struct kunit_case test_cases[] = {
> + KUNIT_CASE(test_single_irq_change),
> + KUNIT_CASE(test_nested_irq_change),
> + KUNIT_CASE(test_multiple_irq_change),
> + KUNIT_CASE(test_irq_save),
> + {},
> +};
> +
> +/* (init and exit are the same */
[Severity: Low]
This isn't a bug, but it looks like there is a missing closing parenthesis
at the end of this comment.
> +static int test_init(struct kunit *test)
> +{
> + TEST_IRQ_ON();
> +
> + return 0;
> +}
> +
> +static void test_exit(struct kunit *test)
> +{
> + TEST_IRQ_ON();
> +}
[Severity: High]
Does this test suite need more robust teardown to protect the kernel from
leaking disabled interrupt states?
If a test case fails to balance local_interrupt_disable() and
local_interrupt_enable(), it will return with hardware interrupts permanently
disabled. Because test_exit() only checks the state but does not repair it,
the KUnit kthread will continue executing with interrupts disabled, which can
lead to a system hang, RCU stall, or softlockup.
Should test_exit() explicitly restore a safe interrupt environment, and
should test_init() fail the test suite if it detects interrupts are already
disabled?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260526152148.30514-1-boqun@kernel.org?part=6
next prev parent reply other threads:[~2026-05-26 18:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 15:21 [PATCH v2 00/12] Refcounted interrupt disable and SpinLockIrq for rust (Part 1) Boqun Feng
2026-05-26 15:21 ` [PATCH v2 01/12] preempt: Track NMI nesting to separate per-CPU counter Boqun Feng
2026-05-26 16:12 ` sashiko-bot
2026-06-04 12:36 ` Boqun Feng
2026-05-26 15:21 ` [PATCH v2 02/12] preempt: Introduce HARDIRQ_DISABLE_BITS Boqun Feng
2026-05-26 15:21 ` [PATCH v2 03/12] preempt: Introduce __preempt_count_{sub, add}_return() Boqun Feng
2026-05-26 15:21 ` [PATCH v2 04/12] openrisc: Include <linux/cpumask.h> in smp.h Boqun Feng
2026-05-26 15:21 ` [PATCH v2 05/12] irq & spin_lock: Add counted interrupt disabling/enabling Boqun Feng
2026-05-26 16:19 ` bot+bpf-ci
2026-05-26 17:54 ` sashiko-bot
2026-05-28 10:43 ` Peter Zijlstra
2026-05-28 14:31 ` Boqun Feng
2026-05-26 15:21 ` [PATCH v2 06/12] irq: Add KUnit test for refcounted interrupt enable/disable Boqun Feng
2026-05-26 18:18 ` sashiko-bot [this message]
2026-05-26 15:21 ` [PATCH v2 07/12] locking: Switch to _irq_{disable,enable}() variants in cleanup guards Boqun Feng
2026-05-28 10:45 ` Peter Zijlstra
2026-05-28 14:31 ` Boqun Feng
2026-05-26 15:21 ` [PATCH v2 08/12] sched: Remove the unused preempt_offset parameter of __cant_sleep() Boqun Feng
2026-05-26 15:21 ` [PATCH v2 09/12] sched: Avoid signed comparison of preempt_count() in __cant_migrate() Boqun Feng
2026-05-26 15:21 ` [PATCH v2 10/12] preempt: Introduce HAS_SEPARATE_PREEMPT_RESCHED_BITS Boqun Feng
2026-05-26 19:57 ` sashiko-bot
2026-06-04 12:40 ` Boqun Feng
2026-05-26 15:21 ` [PATCH v2 11/12] arm64: sched/preempt: Enable HAS_SEPARATE_PREEMPT_RESCHED_BITS Boqun Feng
2026-05-28 10:50 ` Peter Zijlstra
2026-05-26 15:21 ` [PATCH v2 12/12] s390/preempt: " Boqun Feng
2026-05-28 10:53 ` Peter Zijlstra
2026-05-28 14:41 ` Boqun Feng
2026-05-28 15:18 ` Heiko Carstens
2026-05-27 16:18 ` [PATCH v2 00/12] Refcounted interrupt disable and SpinLockIrq for rust (Part 1) Peter Zijlstra
2026-05-27 16:33 ` Boqun Feng
2026-06-03 19:20 ` Boqun Feng
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=20260526181826.58EAD1F000E9@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 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.