From: sashiko-bot@kernel.org
To: "Boqun Feng" <boqun@kernel.org>
Cc: ojeda@kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH v3 06/13] irq: Add KUnit test for refcounted interrupt enable/disable
Date: Fri, 05 Jun 2026 05:53:14 +0000 [thread overview]
Message-ID: <20260605055315.3E96E1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260605054128.5925-7-boqun@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The refcount interrupt test is unconditionally compiled and executed whenever CONFIG_KUNIT is enabled, causing unnecessary kernel bloat.
--
commit 0f70b0c848721241ef0e28b62356b6ec7b9daf4b
Author: Lyude Paul <lyude@redhat.com>
irq: Add KUnit test for refcounted interrupt enable/disable
This commit introduces a suite of KUnit tests to verify the behavior of the
new 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 gated behind a dedicated Kconfig option instead of
compiling unconditionally when KUnit is enabled?
Using CONFIG_KUNIT directly forces the test to compile and execute whenever
the KUnit framework is enabled, even when a user is testing unrelated
subsystems.
Could this reuse the existing CONFIG_IRQ_KUNIT_TEST (like irq_test.o on
the line above it) or use a new, dedicated configuration option to allow
granular test selection?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260605054128.5925-1-boqun@kernel.org?part=6
next prev parent reply other threads:[~2026-06-05 5:53 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 [this message]
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=20260605055315.3E96E1F00893@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