On Wed, Apr 22, 2026 at 2:21 PM David Gow <[email protected]> wrote: > > Le 20/04/2026 à 8:28 PM, Albert Esteve a écrit : > > From: Alessandro Carminati <[email protected]> > > > > KUnit support is not consistently present across distributions, some > > include it in their stock kernels, while others do not. > > While both KUNIT and KUNIT_SUPPRESS_BACKTRACE can be considered debug > > features, the fact that some distros ship with KUnit enabled means it's > > important to minimize the runtime impact of this patch. > > > > To that end, this patch adds an atomic counter that tracks the number > > of active suppressions. __kunit_is_suppressed_warning() checks this > > counter first and returns immediately when no suppressions are active, > > avoiding RCU-protected list traversal in the common case. > > > > Signed-off-by: Alessandro Carminati <[email protected]> > > Signed-off-by: Albert Esteve <[email protected]> > > --- > > I'm not sure how much of an improvement this is. > > It might be worth putting things behind the kunit_running static branch. > > You could even add a new kunit_has_suppressed_warnings static branch, > though I doubt anyone's too worried about the runtime performance of > WARN() during testing, but with no suppressions, so it's likely not > worth it. > > Have a look at, e.g., kunit_fail_current_test() in > include/kunit/test-bug.h, which uses the existing hooks implementation > and static branch to reduce the overhead as much as I'd expect we need. > That'd also potentially let you move the backtrace suppression code into > the kunit.ko module, so you're not even paying more than ~a pointer's > worth of memory if no tests are even loaded.
Agreed. This patch can be removed entirely once I integrate it into the hooks infrastructure as discussed. The kunit_running static branch is indeed a better fast-path than the counter, and leverages existing architecture. > > Cheers, > -- David >
