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 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.