* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-13 13:00 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Greg KH, Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel
In-Reply-To: <87ecjfmpzj.fsf@trenco.lwn.net>
On Wed, May 13, 2026 at 06:52:00AM -0600, Jonathan Corbet wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> > On Wed, May 13, 2026 at 12:29:34PM +0200, Greg KH wrote:
> >> On Tue, May 12, 2026 at 11:20:51AM -0600, Jonathan Corbet wrote:
> >> > Willy Tarreau <w@1wt.eu> writes:
>
> >> > > +* **Capability-based protection**:
> >> > > +
> >> > > + * users not having the ``CAP_SYS_ADMIN`` capability may not alter the
> >> > > + kernel's configuration, memory nor state, change other users' view of the
> >> > > + file system layout, grant any user capabilities they do not have, nor
> >> > > + affect the system's availability (shutdown, reboot, panic, hang, or making
> >> > > + the system unresponsive via unbounded resource exhaustion).
> >> >
> >> > That is pretty demonstrably not true, and will likely elicit challenges
> >> > at some point. There are a lot of "make me root" capabilities that
> >> > enable users to do all of those things; consider CAP_DAC_OVERRIDE as an
> >> > obvious example. I think that just about all of the capabilities will
> >> > enable at least one of those things - that's why the capabilities exist
> >> > in the first place. So I think this needs to be written far more
> >> > generally.
> >>
> >> You are right, there are more capabilities, but we get bug reports all
> >> the time that basically come down to "a user with CAP_SYS_ADMIN can go
> >> and do..." which are pointless for us to be handling. Just got one a
> >> few minutes ago, so LLMs are churning this crap out quite frequently.
> >>
> >> So any rewording of this to prevent us from getting these pointless
> >> reports would be great.
> >
> > Honestly we're seeing this through the angle of a patch that lists a
> > single paragraph but the doc is already becoming quite long. I'm a bit
> > afraid of adding long enumerations, or sentences which do not immediately
> > translate to something recognizable by reporters. Not that it cannot be
> > done, but I think the current situation warrants incremental improvements
> > by fixing what doesn't work well. And indeed most of the capabilities
> > based reports currently revolve around "I already have CAP_{SYS,NET}_ADMIN
> > and ...". That might remain a good start for now.
>
> I definitely wouldn't argue for making it longer, and enumerating all of
> the make-me-root capabilities would be silly. I would consider just
> replacing CAP_SYS_ADMIN with "elevated capabilities" or some such. That
> might rule out legitimate reports where some capability provides an
> access it shouldn't, but I suspect you could live with that :)
I think it could indeed work like this, without denaturating the rest
of the paragraph and having broader coverage. Do you think you could
amend/update it ? I'm not trying to add you any burden, it's just that
it will take me more time before I provide an update :-/
Thanks,
Willy
^ permalink raw reply
* Re: [PATCH v3 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports
From: Willy Tarreau @ 2026-05-13 12:58 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Greg KH, Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel
In-Reply-To: <87a4u3mpxk.fsf@trenco.lwn.net>
On Wed, May 13, 2026 at 06:53:11AM -0600, Jonathan Corbet wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> > On Wed, May 13, 2026 at 12:30:10PM +0200, Greg KH wrote:
> >> > One nit:
> >> >
> >> > > + * **Impact Evaluation**: Many AI-generated reports lack an understanding of
> >> > > + the kernel's threat model and go to great lengths inventing theoretical
> >> > > + consequences.
> >> >
> >> > If only we had a shiny new document describing that threat model that we
> >> > could reference here... :)
> >>
> >> Ah yes, a link to that would make things better, but don't we have that
> >> elsewhere in this series?
> >
> > It's in the same patch, I think Jon was sarcastic here. I thought I had
> > addressed that one but apparently I was wrong :-/
>
> I'm just saying that this particular text should link to that document,
> don't make readers go searching for it. I can certainly add a patch
> doing that if you like.
That would be kind, thank you Jon. Feel free to modify my patch if you
haven't published it if you prefer.
Thanks!
willy
^ permalink raw reply
* Re: [PATCH v3 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports
From: Jonathan Corbet @ 2026-05-13 12:53 UTC (permalink / raw)
To: Willy Tarreau, Greg KH
Cc: Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel
In-Reply-To: <agRfXQvN7ZDTNGQG@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
> On Wed, May 13, 2026 at 12:30:10PM +0200, Greg KH wrote:
>> > One nit:
>> >
>> > > + * **Impact Evaluation**: Many AI-generated reports lack an understanding of
>> > > + the kernel's threat model and go to great lengths inventing theoretical
>> > > + consequences.
>> >
>> > If only we had a shiny new document describing that threat model that we
>> > could reference here... :)
>>
>> Ah yes, a link to that would make things better, but don't we have that
>> elsewhere in this series?
>
> It's in the same patch, I think Jon was sarcastic here. I thought I had
> addressed that one but apparently I was wrong :-/
I'm just saying that this particular text should link to that document,
don't make readers go searching for it. I can certainly add a patch
doing that if you like.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Jonathan Corbet @ 2026-05-13 12:52 UTC (permalink / raw)
To: Willy Tarreau, Greg KH
Cc: Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel
In-Reply-To: <agRfFoMC2Gcu0Esz@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
> On Wed, May 13, 2026 at 12:29:34PM +0200, Greg KH wrote:
>> On Tue, May 12, 2026 at 11:20:51AM -0600, Jonathan Corbet wrote:
>> > Willy Tarreau <w@1wt.eu> writes:
>> > > +* **Capability-based protection**:
>> > > +
>> > > + * users not having the ``CAP_SYS_ADMIN`` capability may not alter the
>> > > + kernel's configuration, memory nor state, change other users' view of the
>> > > + file system layout, grant any user capabilities they do not have, nor
>> > > + affect the system's availability (shutdown, reboot, panic, hang, or making
>> > > + the system unresponsive via unbounded resource exhaustion).
>> >
>> > That is pretty demonstrably not true, and will likely elicit challenges
>> > at some point. There are a lot of "make me root" capabilities that
>> > enable users to do all of those things; consider CAP_DAC_OVERRIDE as an
>> > obvious example. I think that just about all of the capabilities will
>> > enable at least one of those things - that's why the capabilities exist
>> > in the first place. So I think this needs to be written far more
>> > generally.
>>
>> You are right, there are more capabilities, but we get bug reports all
>> the time that basically come down to "a user with CAP_SYS_ADMIN can go
>> and do..." which are pointless for us to be handling. Just got one a
>> few minutes ago, so LLMs are churning this crap out quite frequently.
>>
>> So any rewording of this to prevent us from getting these pointless
>> reports would be great.
>
> Honestly we're seeing this through the angle of a patch that lists a
> single paragraph but the doc is already becoming quite long. I'm a bit
> afraid of adding long enumerations, or sentences which do not immediately
> translate to something recognizable by reporters. Not that it cannot be
> done, but I think the current situation warrants incremental improvements
> by fixing what doesn't work well. And indeed most of the capabilities
> based reports currently revolve around "I already have CAP_{SYS,NET}_ADMIN
> and ...". That might remain a good start for now.
I definitely wouldn't argue for making it longer, and enumerating all of
the make-me-root capabilities would be silly. I would consider just
replacing CAP_SYS_ADMIN with "elevated capabilities" or some such. That
might rule out legitimate reports where some capability provides an
access it shouldn't, but I suspect you could live with that :)
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports
From: Willy Tarreau @ 2026-05-13 11:24 UTC (permalink / raw)
To: Greg KH
Cc: Jonathan Corbet, Leon Romanovsky, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <2026051353-apricot-kleenex-fa57@gregkh>
On Wed, May 13, 2026 at 12:30:10PM +0200, Greg KH wrote:
> > One nit:
> >
> > > + * **Impact Evaluation**: Many AI-generated reports lack an understanding of
> > > + the kernel's threat model and go to great lengths inventing theoretical
> > > + consequences.
> >
> > If only we had a shiny new document describing that threat model that we
> > could reference here... :)
>
> Ah yes, a link to that would make things better, but don't we have that
> elsewhere in this series?
It's in the same patch, I think Jon was sarcastic here. I thought I had
addressed that one but apparently I was wrong :-/
willy
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-13 11:23 UTC (permalink / raw)
To: Greg KH
Cc: Jonathan Corbet, Leon Romanovsky, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <2026051333-puzzle-smokiness-8096@gregkh>
On Wed, May 13, 2026 at 12:29:34PM +0200, Greg KH wrote:
> On Tue, May 12, 2026 at 11:20:51AM -0600, Jonathan Corbet wrote:
> > Willy Tarreau <w@1wt.eu> writes:
> >
> > > The use of automated tools to find bugs in random locations of the kernel
> > > induces a raise of security reports even if most of them should just be
> > > reported as regular bugs. This patch is an attempt at drawing a line
> > > between what qualifies as a security bug and what does not, hoping to
> > > improve the situation and ease decision on the reporter's side.
> > >
> > > It defers the enumeration to a new file, threat-model.rst, that tries
> > > to enumerate various classes of issues that are and are not security
> > > bugs. This should permit to more easily update this file for various
> > > subsystem-specific rules without having to revisit the security bug
> > > reporting guide.
> >
> > One thing here:
> >
> > [...]
> >
> > > +* **Capability-based protection**:
> > > +
> > > + * users not having the ``CAP_SYS_ADMIN`` capability may not alter the
> > > + kernel's configuration, memory nor state, change other users' view of the
> > > + file system layout, grant any user capabilities they do not have, nor
> > > + affect the system's availability (shutdown, reboot, panic, hang, or making
> > > + the system unresponsive via unbounded resource exhaustion).
> >
> > That is pretty demonstrably not true, and will likely elicit challenges
> > at some point. There are a lot of "make me root" capabilities that
> > enable users to do all of those things; consider CAP_DAC_OVERRIDE as an
> > obvious example. I think that just about all of the capabilities will
> > enable at least one of those things - that's why the capabilities exist
> > in the first place. So I think this needs to be written far more
> > generally.
>
> You are right, there are more capabilities, but we get bug reports all
> the time that basically come down to "a user with CAP_SYS_ADMIN can go
> and do..." which are pointless for us to be handling. Just got one a
> few minutes ago, so LLMs are churning this crap out quite frequently.
>
> So any rewording of this to prevent us from getting these pointless
> reports would be great.
Honestly we're seeing this through the angle of a patch that lists a
single paragraph but the doc is already becoming quite long. I'm a bit
afraid of adding long enumerations, or sentences which do not immediately
translate to something recognizable by reporters. Not that it cannot be
done, but I think the current situation warrants incremental improvements
by fixing what doesn't work well. And indeed most of the capabilities
based reports currently revolve around "I already have CAP_{SYS,NET}_ADMIN
and ...". That might remain a good start for now.
> > As a lower-priority thing, lockdown mode is meant to at least try to
> > provide some stronger guarantees, and lockdown circumvention seems to be
> > normally be viewed as a security bug. Worth a mention?
>
> lockdown issues are best discussed on the list where the lockdown people
> are as most of us feel that really isn't a "security" thing at all :)
I don't remember when we last got a report for it but it's not frequent.
Again, I think we should continue to focus on efficiency, i.e. the number
of improperly routed reports we can stop per word written/read.
Willy
^ permalink raw reply
* Re: [PATCH v3 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports
From: Greg KH @ 2026-05-13 10:30 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Willy Tarreau, Leon Romanovsky, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <87se7wo861.fsf@trenco.lwn.net>
On Tue, May 12, 2026 at 11:21:42AM -0600, Jonathan Corbet wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> > AI tools are increasingly used to assist in bug discovery. While these
> > tools can identify valid issues, reports that are submitted without
> > manual verification often lack context, contain speculative impact
> > assessments, or include unnecessary formatting. Such reports increase
> > triage effort, waste maintainers' time and may be ignored.
> >
> > Reports where the reporter has verified the issue and the proposed fix
> > typically meet quality standards. This documentation outlines specific
> > requirements for length, formatting, and impact evaluation to reduce
> > the effort needed to deal with these reports.
> >
> > Cc: Greg KH <gregkh@linuxfoundation.org>
> > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Reviewed-by: Leon Romanovsky <leon@kernel.org>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > ---
> > Documentation/process/security-bugs.rst | 57 +++++++++++++++++++++++++
> > 1 file changed, 57 insertions(+)
>
> One nit:
>
> > + * **Impact Evaluation**: Many AI-generated reports lack an understanding of
> > + the kernel's threat model and go to great lengths inventing theoretical
> > + consequences.
>
> If only we had a shiny new document describing that threat model that we
> could reference here... :)
Ah yes, a link to that would make things better, but don't we have that
elsewhere in this series?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Greg KH @ 2026-05-13 10:29 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Willy Tarreau, Leon Romanovsky, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <87wlx8o87g.fsf@trenco.lwn.net>
On Tue, May 12, 2026 at 11:20:51AM -0600, Jonathan Corbet wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> > The use of automated tools to find bugs in random locations of the kernel
> > induces a raise of security reports even if most of them should just be
> > reported as regular bugs. This patch is an attempt at drawing a line
> > between what qualifies as a security bug and what does not, hoping to
> > improve the situation and ease decision on the reporter's side.
> >
> > It defers the enumeration to a new file, threat-model.rst, that tries
> > to enumerate various classes of issues that are and are not security
> > bugs. This should permit to more easily update this file for various
> > subsystem-specific rules without having to revisit the security bug
> > reporting guide.
>
> One thing here:
>
> [...]
>
> > +* **Capability-based protection**:
> > +
> > + * users not having the ``CAP_SYS_ADMIN`` capability may not alter the
> > + kernel's configuration, memory nor state, change other users' view of the
> > + file system layout, grant any user capabilities they do not have, nor
> > + affect the system's availability (shutdown, reboot, panic, hang, or making
> > + the system unresponsive via unbounded resource exhaustion).
>
> That is pretty demonstrably not true, and will likely elicit challenges
> at some point. There are a lot of "make me root" capabilities that
> enable users to do all of those things; consider CAP_DAC_OVERRIDE as an
> obvious example. I think that just about all of the capabilities will
> enable at least one of those things - that's why the capabilities exist
> in the first place. So I think this needs to be written far more
> generally.
You are right, there are more capabilities, but we get bug reports all
the time that basically come down to "a user with CAP_SYS_ADMIN can go
and do..." which are pointless for us to be handling. Just got one a
few minutes ago, so LLMs are churning this crap out quite frequently.
So any rewording of this to prevent us from getting these pointless
reports would be great.
> As a lower-priority thing, lockdown mode is meant to at least try to
> provide some stronger guarantees, and lockdown circumvention seems to be
> normally be viewed as a security bug. Worth a mention?
lockdown issues are best discussed on the list where the lockdown people
are as most of us feel that really isn't a "security" thing at all :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH v10 4/4] kunit: Add documentation for warning backtrace suppression API
From: Albert Esteve @ 2026-05-13 7:30 UTC (permalink / raw)
To: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-riscv, linux-doc, peterz, Guenter Roeck,
Linux Kernel Functional Testing, Alessandro Carminati,
Albert Esteve, Dan Carpenter, Kees Cook
In-Reply-To: <20260513-kunit_add_support-v10-0-e379d206c8cd@redhat.com>
From: Guenter Roeck <linux@roeck-us.net>
Document API functions for suppressing warning backtraces.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
Reviewed-by: David Gow <david@davidgow.net>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
Documentation/dev-tools/kunit/usage.rst | 46 ++++++++++++++++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index ebd06f5ea4550..1c78dfff94e8a 100644
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@@ -157,6 +157,50 @@ Alternatively, one can take full control over the error message by using
if (some_setup_function())
KUNIT_FAIL(test, "Failed to setup thing for testing");
+Suppressing warning backtraces
+------------------------------
+
+Some unit tests trigger warning backtraces either intentionally or as a side
+effect. Such backtraces are normally undesirable since they distract from
+the actual test and may result in the impression that there is a problem.
+
+Backtraces can be suppressed with **task-scoped suppression**: while
+suppression is active on the current task, the backtrace and stack dump from
+``WARN*()``, ``WARN_ON*()``, and related macros on that task are suppressed.
+Two API forms are available.
+
+- Scoped suppression is the simplest form. Wrap the code that triggers
+ warnings in a ``kunit_warning_suppress()`` block:
+
+.. code-block:: c
+
+ static void some_test(struct kunit *test)
+ {
+ kunit_warning_suppress(test) {
+ trigger_backtrace();
+ KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
+ }
+ }
+
+.. note::
+ The warning count must be checked inside the block; the suppression handle
+ is not accessible after the block exits.
+
+- Direct functions return an explicit handle pointer. Use them when the handle
+ needs to be retained or passed across helper functions:
+
+.. code-block:: c
+
+ static void some_test(struct kunit *test)
+ {
+ struct kunit_suppressed_warning *w;
+
+ w = kunit_start_suppress_warning(test);
+ trigger_backtrace();
+ kunit_end_suppress_warning(test, w);
+
+ KUNIT_EXPECT_EQ(test, kunit_suppressed_warning_count(w), 1);
+ }
Test Suites
~~~~~~~~~~~
@@ -1211,4 +1255,4 @@ For example:
dev_managed_string = devm_kstrdup(fake_device, "Hello, World!");
// Everything is cleaned up automatically when the test ends.
- }
\ No newline at end of file
+ }
--
2.53.0
^ permalink raw reply related
* [PATCH v10 3/4] drm: Suppress intentional warning backtraces in scaling unit tests
From: Albert Esteve @ 2026-05-13 7:30 UTC (permalink / raw)
To: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-riscv, linux-doc, peterz, Guenter Roeck,
Linux Kernel Functional Testing, Maíra Canal,
Alessandro Carminati, Albert Esteve, Dan Carpenter, Simona Vetter
In-Reply-To: <20260513-kunit_add_support-v10-0-e379d206c8cd@redhat.com>
From: Guenter Roeck <linux@roeck-us.net>
The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
intentionally trigger warning backtraces by providing bad parameters to
the tested functions. What is tested is the return value, not the existence
of a warning backtrace. Suppress the backtraces to avoid clogging the
kernel log and distraction from real problems. Additionally, the
suppression API allows to actually ensure a warning was triggered,
without parsing any kernel logs and keeping them clean.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Maíra Canal <mcanal@igalia.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: David Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
Acked-by: David Gow <david@davidgow.net>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
drivers/gpu/drm/tests/drm_rect_test.c | 32 ++++++++++++++++++++++++++------
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_rect_test.c b/drivers/gpu/drm/tests/drm_rect_test.c
index 17e1f34b76101..ccc741b6191ff 100644
--- a/drivers/gpu/drm/tests/drm_rect_test.c
+++ b/drivers/gpu/drm/tests/drm_rect_test.c
@@ -10,6 +10,7 @@
#include <drm/drm_rect.h>
#include <drm/drm_mode.h>
+#include <linux/limits.h>
#include <linux/string_helpers.h>
#include <linux/errno.h>
@@ -407,10 +408,20 @@ KUNIT_ARRAY_PARAM(drm_rect_scale, drm_rect_scale_cases, drm_rect_scale_case_desc
static void drm_test_rect_calc_hscale(struct kunit *test)
{
const struct drm_rect_scale_case *params = test->param_value;
- int scaling_factor;
+ int expected_warnings = params->expected_scaling_factor == -EINVAL;
+ int scaling_factor = INT_MIN;
- scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
- params->min_range, params->max_range);
+ /*
+ * drm_rect_calc_hscale() generates a warning backtrace whenever bad
+ * parameters are passed to it. This affects unit tests with -EINVAL
+ * error code in expected_scaling_factor.
+ */
+ kunit_warning_suppress(test) {
+ scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
+ params->min_range,
+ params->max_range);
+ KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, expected_warnings);
+ }
KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
}
@@ -418,10 +429,19 @@ static void drm_test_rect_calc_hscale(struct kunit *test)
static void drm_test_rect_calc_vscale(struct kunit *test)
{
const struct drm_rect_scale_case *params = test->param_value;
- int scaling_factor;
+ int expected_warnings = params->expected_scaling_factor == -EINVAL;
+ int scaling_factor = INT_MIN;
- scaling_factor = drm_rect_calc_vscale(¶ms->src, ¶ms->dst,
- params->min_range, params->max_range);
+ /*
+ * drm_rect_calc_vscale() generates a warning backtrace whenever bad
+ * parameters are passed to it. This affects unit tests with -EINVAL
+ * error code in expected_scaling_factor.
+ */
+ kunit_warning_suppress(test) {
+ scaling_factor = drm_rect_calc_vscale(¶ms->src, ¶ms->dst,
+ params->min_range, params->max_range);
+ KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, expected_warnings);
+ }
KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
}
--
2.53.0
^ permalink raw reply related
* [PATCH v10 2/4] kunit: Add backtrace suppression self-tests
From: Albert Esteve @ 2026-05-13 7:30 UTC (permalink / raw)
To: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-riscv, linux-doc, peterz, Guenter Roeck,
Linux Kernel Functional Testing, Alessandro Carminati,
Albert Esteve, Dan Carpenter, Kees Cook
In-Reply-To: <20260513-kunit_add_support-v10-0-e379d206c8cd@redhat.com>
From: Guenter Roeck <linux@roeck-us.net>
Add unit tests to verify that warning backtrace suppression works.
Tests cover both API forms:
- Scoped: kunit_warning_suppress() with in-block count verification
and post-block inactivity check.
- Direct functions: kunit_start/end_suppress_warning() with
sequential independent suppression blocks and per-block counts.
Furthermore, tests verify incremental warning counting, that
kunit_has_active_suppress_warning() transitions correctly around
suppression boundaries, and that suppression active in the test
kthread does not leak to a separate kthread.
If backtrace suppression does _not_ work, the unit tests will likely
trigger unsuppressed backtraces, which should actually help to get
the affected architectures / platforms fixed.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
Reviewed-by: David Gow <david@davidgow.net>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
lib/kunit/Makefile | 1 +
lib/kunit/backtrace-suppression-test.c | 196 +++++++++++++++++++++++++++++++++
2 files changed, 197 insertions(+)
diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
index 4592f9d0aa8dd..2e8a6b71a2ab0 100644
--- a/lib/kunit/Makefile
+++ b/lib/kunit/Makefile
@@ -22,6 +22,7 @@ obj-$(if $(CONFIG_KUNIT),y) += hooks.o
obj-$(CONFIG_KUNIT_TEST) += kunit-test.o
obj-$(CONFIG_KUNIT_TEST) += platform-test.o
+obj-$(CONFIG_KUNIT_TEST) += backtrace-suppression-test.o
# string-stream-test compiles built-in only.
ifeq ($(CONFIG_KUNIT_TEST),y)
diff --git a/lib/kunit/backtrace-suppression-test.c b/lib/kunit/backtrace-suppression-test.c
new file mode 100644
index 0000000000000..831a60f3521fa
--- /dev/null
+++ b/lib/kunit/backtrace-suppression-test.c
@@ -0,0 +1,196 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test for suppressing warning tracebacks.
+ *
+ * Copyright (C) 2024, Guenter Roeck
+ * Author: Guenter Roeck <linux@roeck-us.net>
+ */
+
+#include <kunit/test.h>
+#include <linux/bug.h>
+#include <linux/completion.h>
+#include <linux/kthread.h>
+
+static void backtrace_suppression_test_warn_direct(struct kunit *test)
+{
+ if (!IS_ENABLED(CONFIG_BUG))
+ kunit_skip(test, "requires CONFIG_BUG");
+
+ kunit_warning_suppress(test) {
+ WARN(1, "This backtrace should be suppressed");
+ /*
+ * Count must be checked inside the scope; the handle
+ * is not accessible after the block exits.
+ */
+ KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
+ }
+ KUNIT_EXPECT_FALSE(test, kunit_has_active_suppress_warning());
+}
+
+static noinline void trigger_backtrace_warn(void)
+{
+ WARN(1, "This backtrace should be suppressed");
+}
+
+static void backtrace_suppression_test_warn_indirect(struct kunit *test)
+{
+ if (!IS_ENABLED(CONFIG_BUG))
+ kunit_skip(test, "requires CONFIG_BUG");
+
+ kunit_warning_suppress(test) {
+ trigger_backtrace_warn();
+ KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
+ }
+}
+
+static void backtrace_suppression_test_warn_multi(struct kunit *test)
+{
+ if (!IS_ENABLED(CONFIG_BUG))
+ kunit_skip(test, "requires CONFIG_BUG");
+
+ kunit_warning_suppress(test) {
+ WARN(1, "This backtrace should be suppressed");
+ trigger_backtrace_warn();
+ KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 2);
+ }
+}
+
+static void backtrace_suppression_test_warn_on_direct(struct kunit *test)
+{
+ if (!IS_ENABLED(CONFIG_BUG))
+ kunit_skip(test, "requires CONFIG_BUG");
+ if (!IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE) && !IS_ENABLED(CONFIG_KALLSYMS))
+ kunit_skip(test, "requires CONFIG_DEBUG_BUGVERBOSE or CONFIG_KALLSYMS");
+
+ kunit_warning_suppress(test) {
+ WARN_ON(1);
+ KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
+ }
+}
+
+static noinline void trigger_backtrace_warn_on(void)
+{
+ WARN_ON(1);
+}
+
+static void backtrace_suppression_test_warn_on_indirect(struct kunit *test)
+{
+ if (!IS_ENABLED(CONFIG_BUG))
+ kunit_skip(test, "requires CONFIG_BUG");
+ if (!IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE))
+ kunit_skip(test, "requires CONFIG_DEBUG_BUGVERBOSE");
+
+ kunit_warning_suppress(test) {
+ trigger_backtrace_warn_on();
+ KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
+ }
+}
+
+static void backtrace_suppression_test_count(struct kunit *test)
+{
+ if (!IS_ENABLED(CONFIG_BUG))
+ kunit_skip(test, "requires CONFIG_BUG");
+
+ kunit_warning_suppress(test) {
+ KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 0);
+
+ WARN(1, "suppressed");
+ KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
+
+ WARN(1, "suppressed again");
+ KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 2);
+ }
+}
+
+static void backtrace_suppression_test_active_state(struct kunit *test)
+{
+ KUNIT_EXPECT_FALSE(test, kunit_has_active_suppress_warning());
+
+ kunit_warning_suppress(test) {
+ KUNIT_EXPECT_TRUE(test, kunit_has_active_suppress_warning());
+ }
+
+ KUNIT_EXPECT_FALSE(test, kunit_has_active_suppress_warning());
+
+ kunit_warning_suppress(test) {
+ KUNIT_EXPECT_TRUE(test, kunit_has_active_suppress_warning());
+ }
+
+ KUNIT_EXPECT_FALSE(test, kunit_has_active_suppress_warning());
+}
+
+static void backtrace_suppression_test_multi_scope(struct kunit *test)
+{
+ struct kunit_suppressed_warning *sw1, *sw2;
+
+ if (!IS_ENABLED(CONFIG_BUG))
+ kunit_skip(test, "requires CONFIG_BUG");
+ if (!IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE))
+ kunit_skip(test, "requires CONFIG_DEBUG_BUGVERBOSE");
+
+ sw1 = kunit_start_suppress_warning(test);
+ trigger_backtrace_warn_on();
+ WARN(1, "suppressed by sw1");
+ kunit_end_suppress_warning(test, sw1);
+
+ sw2 = kunit_start_suppress_warning(test);
+ WARN(1, "suppressed by sw2");
+ kunit_end_suppress_warning(test, sw2);
+
+ KUNIT_EXPECT_EQ(test, kunit_suppressed_warning_count(sw1), 2);
+ KUNIT_EXPECT_EQ(test, kunit_suppressed_warning_count(sw2), 1);
+}
+
+struct cross_kthread_data {
+ bool was_active;
+ struct completion done;
+};
+
+static int cross_kthread_fn(void *data)
+{
+ struct cross_kthread_data *d = data;
+
+ d->was_active = kunit_has_active_suppress_warning();
+ complete(&d->done);
+ return 0;
+}
+
+static void backtrace_suppression_test_cross_kthread(struct kunit *test)
+{
+ struct cross_kthread_data data;
+ struct task_struct *task;
+
+ data.was_active = false;
+ init_completion(&data.done);
+
+ kunit_warning_suppress(test) {
+ task = kthread_run(cross_kthread_fn, &data, "kunit-cross-test");
+ KUNIT_ASSERT_FALSE(test, IS_ERR(task));
+ wait_for_completion(&data.done);
+ kthread_stop(task);
+ }
+
+ KUNIT_EXPECT_FALSE(test, data.was_active);
+}
+
+static struct kunit_case backtrace_suppression_test_cases[] = {
+ KUNIT_CASE(backtrace_suppression_test_warn_direct),
+ KUNIT_CASE(backtrace_suppression_test_warn_indirect),
+ KUNIT_CASE(backtrace_suppression_test_warn_multi),
+ KUNIT_CASE(backtrace_suppression_test_warn_on_direct),
+ KUNIT_CASE(backtrace_suppression_test_warn_on_indirect),
+ KUNIT_CASE(backtrace_suppression_test_count),
+ KUNIT_CASE(backtrace_suppression_test_active_state),
+ KUNIT_CASE(backtrace_suppression_test_multi_scope),
+ KUNIT_CASE(backtrace_suppression_test_cross_kthread),
+ {}
+};
+
+static struct kunit_suite backtrace_suppression_test_suite = {
+ .name = "backtrace-suppression-test",
+ .test_cases = backtrace_suppression_test_cases,
+};
+kunit_test_suites(&backtrace_suppression_test_suite);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("KUnit test to verify warning backtrace suppression");
--
2.53.0
^ permalink raw reply related
* [PATCH v10 1/4] bug/kunit: Core support for suppressing warning backtraces
From: Albert Esteve @ 2026-05-13 7:30 UTC (permalink / raw)
To: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-riscv, linux-doc, peterz, Alessandro Carminati,
Guenter Roeck, Kees Cook, Albert Esteve
In-Reply-To: <20260513-kunit_add_support-v10-0-e379d206c8cd@redhat.com>
From: Alessandro Carminati <acarmina@redhat.com>
Some unit tests intentionally trigger warning backtraces by passing bad
parameters to kernel API functions. Such unit tests typically check the
return value from such calls, not the existence of the warning backtrace.
Such intentionally generated warning backtraces are neither desirable
nor useful for a number of reasons:
- They can result in overlooked real problems.
- A warning that suddenly starts to show up in unit tests needs to be
investigated and has to be marked to be ignored, for example by
adjusting filter scripts. Such filters are ad hoc because there is
no real standard format for warnings. On top of that, such filter
scripts would require constant maintenance.
Solve the problem by providing a means to suppress warning backtraces
originating from the current kthread while executing test code. Since
each KUnit test runs in its own kthread, this effectively scopes
suppression to the test that enabled it. Limit changes to generic code
to the absolute minimum.
Implementation details:
Suppression is integrated into the existing KUnit hooks infrastructure
in test-bug.h, reusing the kunit_running static branch for zero
overhead when no tests are running.
Suppression is checked at three points in the warning path:
- In warn_slowpath_fmt(), the check runs before any output, fully
suppressing both message and backtrace. This covers architectures
without __WARN_FLAGS.
- In __warn_printk(), the check suppresses the warning message text.
This covers architectures that define __WARN_FLAGS but not their own
__WARN_printf (arm64, loongarch, parisc, powerpc, riscv, sh), where
the message is printed before the trap enters __report_bug().
- In __report_bug(), the check runs before __warn() is called,
suppressing the backtrace and stack dump.
To avoid double-counting on architectures where both __warn_printk()
and __report_bug() run for the same warning, kunit_is_suppressed_warning()
takes a bool parameter: true to increment the suppression counter
(used in warn_slowpath_fmt and __report_bug), false to check only
(used in __warn_printk).
The suppression state is dynamically allocated via kunit_kzalloc() and
tied to the KUnit test lifecycle via kunit_add_action(), ensuring
automatic cleanup at test exit. Writer-side access to the global
suppression list is serialized with a spinlock; readers use RCU.
Two API forms are provided:
- kunit_warning_suppress(test) { ... }: scoped, uses __cleanup for
automatic teardown on scope exit, kunit_add_action() as safety net
for abnormal exits (e.g. kthread_exit from failed assertions).
Suppression handle is only accessible inside the block.
- kunit_start/end_suppress_warning(test): direct functions returning
an explicit handle, for retaining the handle within the test,
or for cross-function usage.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Reviewed-by: David Gow <david@davidgow.net>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
include/kunit/test-bug.h | 26 +++++++++++
include/kunit/test.h | 98 ++++++++++++++++++++++++++++++++++++++
kernel/panic.c | 11 +++++
lib/bug.c | 14 +++++-
lib/kunit/Makefile | 3 +-
lib/kunit/bug.c | 119 +++++++++++++++++++++++++++++++++++++++++++++++
lib/kunit/hooks-impl.h | 2 +
7 files changed, 270 insertions(+), 3 deletions(-)
diff --git a/include/kunit/test-bug.h b/include/kunit/test-bug.h
index 47aa8f21ccce8..99869029fc686 100644
--- a/include/kunit/test-bug.h
+++ b/include/kunit/test-bug.h
@@ -10,6 +10,7 @@
#define _KUNIT_TEST_BUG_H
#include <linux/stddef.h> /* for NULL */
+#include <linux/types.h> /* for bool */
#if IS_ENABLED(CONFIG_KUNIT)
@@ -23,6 +24,7 @@ DECLARE_STATIC_KEY_FALSE(kunit_running);
extern struct kunit_hooks_table {
__printf(3, 4) void (*fail_current_test)(const char*, int, const char*, ...);
void *(*get_static_stub_address)(struct kunit *test, void *real_fn_addr);
+ bool (*is_suppressed_warning)(bool count);
} kunit_hooks;
/**
@@ -60,9 +62,33 @@ static inline struct kunit *kunit_get_current_test(void)
} \
} while (0)
+/**
+ * kunit_is_suppressed_warning() - Check if warnings are being suppressed
+ * by the current KUnit test.
+ * @count: if true, increment the suppression counter on match.
+ *
+ * Returns true if the current task has active warning suppression.
+ * Uses the kunit_running static branch for zero overhead when no tests run.
+ *
+ * A single WARN*() may traverse multiple call sites in the warning path
+ * (e.g., __warn_printk() and __report_bug()). Pass @count = true at the
+ * primary suppression point to count each warning exactly once, and
+ * @count = false at secondary points to suppress output without
+ * inflating the count.
+ */
+static inline bool kunit_is_suppressed_warning(bool count)
+{
+ if (!static_branch_unlikely(&kunit_running))
+ return false;
+
+ return kunit_hooks.is_suppressed_warning &&
+ kunit_hooks.is_suppressed_warning(count);
+}
+
#else
static inline struct kunit *kunit_get_current_test(void) { return NULL; }
+static inline bool kunit_is_suppressed_warning(bool count) { return false; }
#define kunit_fail_current_test(fmt, ...) do {} while (0)
diff --git a/include/kunit/test.h b/include/kunit/test.h
index 9cd1594ab697d..be71612f61655 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -1795,4 +1795,102 @@ do { \
// include resource.h themselves if they need it.
#include <kunit/resource.h>
+/*
+ * Warning backtrace suppression API.
+ *
+ * Suppresses WARN*() backtraces on the current task while active. Two forms
+ * are provided:
+ *
+ * - Scoped: kunit_warning_suppress(test) { ... }
+ * Suppression is active for the duration of the block. On normal exit,
+ * the for-loop increment deactivates suppression. On early exit (break,
+ * return, goto), the __cleanup attribute fires. On kthread_exit() (e.g.,
+ * a failed KUnit assertion), kunit_add_action() cleans up at test
+ * teardown. The suppression handle is only accessible inside the block,
+ * so warning counts must be checked before the block exits.
+ *
+ * - Direct: kunit_start_suppress_warning() / kunit_end_suppress_warning()
+ * The underlying functions, returning an explicit handle pointer. Use
+ * when the handle needs to be retained (e.g., for post-suppression
+ * count checks) or passed across helper functions.
+ */
+struct kunit_suppressed_warning;
+
+struct kunit_suppressed_warning *
+kunit_start_suppress_warning(struct kunit *test);
+void kunit_end_suppress_warning(struct kunit *test,
+ struct kunit_suppressed_warning *w);
+int kunit_suppressed_warning_count(struct kunit_suppressed_warning *w);
+void __kunit_suppress_auto_cleanup(struct kunit_suppressed_warning **wp);
+bool kunit_has_active_suppress_warning(void);
+
+/**
+ * kunit_warning_suppress() - Suppress WARN*() backtraces for the duration
+ * of a block.
+ * @test: The test context object.
+ *
+ * Scoped form of the suppression API. Suppression starts when the block is
+ * entered and ends automatically when the block exits through any path. See
+ * the section comment above for the cleanup guarantees on each exit path.
+ * Fails the test if suppression is already active; nesting is not supported.
+ *
+ * The warning count can be checked inside the block via
+ * KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(). The handle is not accessible
+ * after the block exits.
+ *
+ * Example::
+ *
+ * kunit_warning_suppress(test) {
+ * trigger_warning();
+ * KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
+ * }
+ */
+#define kunit_warning_suppress(test) \
+ for (struct kunit_suppressed_warning *__kunit_suppress \
+ __cleanup(__kunit_suppress_auto_cleanup) = \
+ kunit_start_suppress_warning(test); \
+ __kunit_suppress; \
+ kunit_end_suppress_warning(test, __kunit_suppress), \
+ __kunit_suppress = NULL)
+
+/**
+ * KUNIT_SUPPRESSED_WARNING_COUNT() - Returns the suppressed warning count.
+ *
+ * Returns the number of WARN*() calls suppressed since the current
+ * suppression block started, or 0 if the handle is NULL. Usable inside a
+ * kunit_warning_suppress() block.
+ */
+#define KUNIT_SUPPRESSED_WARNING_COUNT() \
+ kunit_suppressed_warning_count(__kunit_suppress)
+
+/**
+ * KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT() - Sets an expectation that the
+ * suppressed warning count equals
+ * @expected.
+ * @test: The test context object.
+ * @expected: an expression that evaluates to the expected warning count.
+ *
+ * Sets an expectation that the number of suppressed WARN*() calls equals
+ * @expected. This is semantically equivalent to
+ * KUNIT_EXPECT_EQ(@test, KUNIT_SUPPRESSED_WARNING_COUNT(), @expected).
+ * See KUNIT_EXPECT_EQ() for more information.
+ */
+#define KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, expected) \
+ KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), expected)
+
+/**
+ * KUNIT_ASSERT_SUPPRESSED_WARNING_COUNT() - Sets an assertion that the
+ * suppressed warning count equals
+ * @expected.
+ * @test: The test context object.
+ * @expected: an expression that evaluates to the expected warning count.
+ *
+ * Sets an assertion that the number of suppressed WARN*() calls equals
+ * @expected. This is the same as KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(),
+ * except it causes an assertion failure (see KUNIT_ASSERT_TRUE()) when the
+ * assertion is not met.
+ */
+#define KUNIT_ASSERT_SUPPRESSED_WARNING_COUNT(test, expected) \
+ KUNIT_ASSERT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), expected)
+
#endif /* _KUNIT_TEST_H */
diff --git a/kernel/panic.c b/kernel/panic.c
index 20feada5319d4..213725b612aa1 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -39,6 +39,7 @@
#include <linux/sys_info.h>
#include <trace/events/error_report.h>
#include <asm/sections.h>
+#include <kunit/test-bug.h>
#define PANIC_TIMER_STEP 100
#define PANIC_BLINK_SPD 18
@@ -1124,6 +1125,11 @@ void warn_slowpath_fmt(const char *file, int line, unsigned taint,
bool rcu = warn_rcu_enter();
struct warn_args args;
+ if (kunit_is_suppressed_warning(true)) {
+ warn_rcu_exit(rcu);
+ return;
+ }
+
pr_warn(CUT_HERE);
if (!fmt) {
@@ -1146,6 +1152,11 @@ void __warn_printk(const char *fmt, ...)
bool rcu = warn_rcu_enter();
va_list args;
+ if (kunit_is_suppressed_warning(false)) {
+ warn_rcu_exit(rcu);
+ return;
+ }
+
pr_warn(CUT_HERE);
va_start(args, fmt);
diff --git a/lib/bug.c b/lib/bug.c
index 224f4cfa4aa31..d99e369bc1103 100644
--- a/lib/bug.c
+++ b/lib/bug.c
@@ -48,6 +48,7 @@
#include <linux/rculist.h>
#include <linux/ftrace.h>
#include <linux/context_tracking.h>
+#include <kunit/test-bug.h>
extern struct bug_entry __start___bug_table[], __stop___bug_table[];
@@ -209,8 +210,6 @@ static enum bug_trap_type __report_bug(struct bug_entry *bug, unsigned long buga
return BUG_TRAP_TYPE_NONE;
}
- disable_trace_on_warning();
-
bug_get_file_line(bug, &file, &line);
fmt = bug_get_format(bug);
@@ -220,6 +219,17 @@ static enum bug_trap_type __report_bug(struct bug_entry *bug, unsigned long buga
no_cut = bug->flags & BUGFLAG_NO_CUT_HERE;
has_args = bug->flags & BUGFLAG_ARGS;
+#ifdef CONFIG_KUNIT
+ /*
+ * Before the once logic so suppressed warnings do not consume
+ * the single-fire budget of WARN_ON_ONCE().
+ */
+ if (warning && kunit_is_suppressed_warning(true))
+ return BUG_TRAP_TYPE_WARN;
+#endif
+
+ disable_trace_on_warning();
+
if (warning && once) {
if (done)
return BUG_TRAP_TYPE_WARN;
diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
index 656f1fa35abcc..4592f9d0aa8dd 100644
--- a/lib/kunit/Makefile
+++ b/lib/kunit/Makefile
@@ -10,7 +10,8 @@ kunit-objs += test.o \
executor.o \
attributes.o \
device.o \
- platform.o
+ platform.o \
+ bug.o
ifeq ($(CONFIG_KUNIT_DEBUGFS),y)
kunit-objs += debugfs.o
diff --git a/lib/kunit/bug.c b/lib/kunit/bug.c
new file mode 100644
index 0000000000000..cdfcbfe80b5df
--- /dev/null
+++ b/lib/kunit/bug.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit helpers for backtrace suppression
+ *
+ * Copyright (C) 2025 Alessandro Carminati <acarmina@redhat.com>
+ * Copyright (C) 2024 Guenter Roeck <linux@roeck-us.net>
+ */
+
+#include <kunit/resource.h>
+#include <linux/export.h>
+#include <linux/rculist.h>
+#include <linux/sched.h>
+#include <linux/spinlock.h>
+
+#include "hooks-impl.h"
+
+struct kunit_suppressed_warning {
+ struct list_head node;
+ struct task_struct *task;
+ struct kunit *test;
+ atomic_t counter;
+};
+
+static LIST_HEAD(suppressed_warnings);
+static DEFINE_SPINLOCK(suppressed_warnings_lock);
+
+static void kunit_suppress_warning_remove(struct kunit_suppressed_warning *w)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&suppressed_warnings_lock, flags);
+ list_del_rcu(&w->node);
+ spin_unlock_irqrestore(&suppressed_warnings_lock, flags);
+ synchronize_rcu(); /* Wait for readers to finish */
+}
+
+KUNIT_DEFINE_ACTION_WRAPPER(kunit_suppress_warning_cleanup,
+ kunit_suppress_warning_remove,
+ struct kunit_suppressed_warning *);
+
+bool kunit_has_active_suppress_warning(void)
+{
+ return __kunit_is_suppressed_warning_impl(false);
+}
+EXPORT_SYMBOL_GPL(kunit_has_active_suppress_warning);
+
+struct kunit_suppressed_warning *
+kunit_start_suppress_warning(struct kunit *test)
+{
+ struct kunit_suppressed_warning *w;
+ unsigned long flags;
+ int ret;
+
+ if (kunit_has_active_suppress_warning()) {
+ KUNIT_FAIL(test, "Another suppression block is already active");
+ return NULL;
+ }
+
+ w = kunit_kzalloc(test, sizeof(*w), GFP_KERNEL);
+ if (!w) {
+ KUNIT_FAIL(test, "Failed to allocate suppression handle.");
+ return NULL;
+ }
+
+ w->task = current;
+ w->test = test;
+
+ spin_lock_irqsave(&suppressed_warnings_lock, flags);
+ list_add_rcu(&w->node, &suppressed_warnings);
+ spin_unlock_irqrestore(&suppressed_warnings_lock, flags);
+
+ ret = kunit_add_action_or_reset(test,
+ kunit_suppress_warning_cleanup, w);
+ if (ret) {
+ KUNIT_FAIL(test, "Failed to add suppression cleanup action.");
+ return NULL;
+ }
+
+ return w;
+}
+EXPORT_SYMBOL_GPL(kunit_start_suppress_warning);
+
+void kunit_end_suppress_warning(struct kunit *test,
+ struct kunit_suppressed_warning *w)
+{
+ if (!w)
+ return;
+ kunit_release_action(test, kunit_suppress_warning_cleanup, w);
+}
+EXPORT_SYMBOL_GPL(kunit_end_suppress_warning);
+
+void __kunit_suppress_auto_cleanup(struct kunit_suppressed_warning **wp)
+{
+ if (*wp)
+ kunit_end_suppress_warning((*wp)->test, *wp);
+}
+EXPORT_SYMBOL_GPL(__kunit_suppress_auto_cleanup);
+
+int kunit_suppressed_warning_count(struct kunit_suppressed_warning *w)
+{
+ return w ? atomic_read(&w->counter) : 0;
+}
+EXPORT_SYMBOL_GPL(kunit_suppressed_warning_count);
+
+bool __kunit_is_suppressed_warning_impl(bool count)
+{
+ struct kunit_suppressed_warning *w;
+
+ guard(rcu)();
+ list_for_each_entry_rcu(w, &suppressed_warnings, node) {
+ if (w->task == current) {
+ if (count)
+ atomic_inc(&w->counter);
+ return true;
+ }
+ }
+
+ return false;
+}
diff --git a/lib/kunit/hooks-impl.h b/lib/kunit/hooks-impl.h
index 4e71b2d0143ba..d8720f2616925 100644
--- a/lib/kunit/hooks-impl.h
+++ b/lib/kunit/hooks-impl.h
@@ -19,6 +19,7 @@ void __printf(3, 4) __kunit_fail_current_test_impl(const char *file,
int line,
const char *fmt, ...);
void *__kunit_get_static_stub_address_impl(struct kunit *test, void *real_fn_addr);
+bool __kunit_is_suppressed_warning_impl(bool count);
/* Code to set all of the function pointers. */
static inline void kunit_install_hooks(void)
@@ -26,6 +27,7 @@ static inline void kunit_install_hooks(void)
/* Install the KUnit hook functions. */
kunit_hooks.fail_current_test = __kunit_fail_current_test_impl;
kunit_hooks.get_static_stub_address = __kunit_get_static_stub_address_impl;
+ kunit_hooks.is_suppressed_warning = __kunit_is_suppressed_warning_impl;
}
#endif /* _KUNIT_HOOKS_IMPL_H */
--
2.53.0
^ permalink raw reply related
* [PATCH v10 0/4] kunit: Add support for suppressing warning backtraces
From: Albert Esteve @ 2026-05-13 7:30 UTC (permalink / raw)
To: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-riscv, linux-doc, peterz, Alessandro Carminati,
Guenter Roeck, Kees Cook, Albert Esteve,
Linux Kernel Functional Testing, Maíra Canal, Dan Carpenter,
Kees Cook, Simona Vetter
Some unit tests intentionally trigger warning backtraces by passing bad
parameters to kernel API functions. Such unit tests typically check the
return value from such calls, not the existence of the warning backtrace.
Such intentionally generated warning backtraces are neither desirable
nor useful for a number of reasons:
- They can result in overlooked real problems.
- A warning that suddenly starts to show up in unit tests needs to be
investigated and has to be marked to be ignored, for example by
adjusting filter scripts. Such filters are ad hoc because there is
no real standard format for warnings. On top of that, such filter
scripts would require constant maintenance.
One option to address the problem would be to add messages such as
"expected warning backtraces start/end here" to the kernel log.
However, that would again require filter scripts, might result in
missing real problematic warning backtraces triggered while the test
is running, and the irrelevant backtrace(s) would still clog the
kernel log.
Solve the problem by providing a means to suppress warning backtraces
originating from the current kthread while executing test code.
Since each KUnit test runs in its own kthread, this effectively scopes
suppression to the test that enabled it, without requiring any
architecture-specific code.
Overview:
Patch#1 Introduces the suppression infrastructure integrated into
KUnit's hook mechanism.
Patch#2 Adds selftests to validate the functionality.
Patch#3 Demonstrates real-world usage in the DRM subsystem.
Patch#4 Documents the new API and usage guidelines.
Design Notes:
Suppression is integrated into the existing KUnit hooks infrastructure,
reusing the kunit_running static branch for zero overhead
when no tests are running. The implementation lives entirely in the
kunit module; only a static-inline wrapper and a function pointer
slot are added to built-in code.
Suppression is checked at three points in the warning path:
- In `warn_slowpath_fmt()` (kernel/panic.c), for architectures without
__WARN_FLAGS. The check runs before any output, fully suppressing
both message and backtrace.
- In `__warn_printk()` (kernel/panic.c), for architectures that define
__WARN_FLAGS but not their own __WARN_printf (arm64, loongarch,
parisc, powerpc, riscv, sh). The check suppresses the warning message
text that is printed before the trap enters __report_bug().
- In `__report_bug()` (lib/bug.c), for architectures that define
__WARN_FLAGS. The check runs before `__warn()` is called, suppressing
the backtrace and stack dump.
To avoid double-counting on architectures where both `__warn_printk()`
and `__report_bug()` run for the same warning, the hook takes a bool
parameter: true to increment the suppression counter, false to suppress
without counting.
The suppression state is dynamically allocated via kunit_kzalloc() and
tied to the KUnit test lifecycle via `kunit_add_action()`, ensuring
automatic cleanup at test exit. Writer-side access to the global
suppression list is serialized with a spinlock; readers use RCU.
Two API forms are provided:
- kunit_warning_suppress(test) { ... }: scoped blocks with automatic
cleanup. The suppression handle is not accessible outside the block,
so warning counts (if needed) must be checked inside. Multiple
suppression blocks are allowed.
- kunit_start/end_suppress_warning(test): direct functions that return
an explicit handle. Use when the handle needs to be retained, or passed
across helpers. Multiple suppression blocks are allowed.
This series is based on the RFC patch and subsequent discussion at
https://patchwork.kernel.org/project/linux-kselftest/patch/02546e59-1afe-4b08-ba81-d94f3b691c9a@moroto.mountain/
and offers a more comprehensive solution of the problem discussed there.
Changes since RFC:
- Introduced CONFIG_KUNIT_SUPPRESS_BACKTRACE
- Minor cleanups and bug fixes
- Added support for all affected architectures
- Added support for counting suppressed warnings
- Added unit tests using those counters
- Added patch to suppress warning backtraces in dev_addr_lists tests
Changes since v1:
- Rebased to v6.9-rc1
- Added Tested-by:, Acked-by:, and Reviewed-by: tags
[I retained those tags since there have been no functional changes]
- Introduced KUNIT_SUPPRESS_BACKTRACE configuration option, enabled by
default.
Changes since v2:
- Rebased to v6.9-rc2
- Added comments to drm warning suppression explaining why it is needed.
- Added patch to move conditional code in arch/sh/include/asm/bug.h
to avoid kerneldoc warning
- Added architecture maintainers to Cc: for architecture specific patches
- No functional changes
Changes since v3:
- Rebased to v6.14-rc6
- Dropped net: "kunit: Suppress lock warning noise at end of dev_addr_lists tests"
since 3db3b62955cd6d73afde05a17d7e8e106695c3b9
- Added __kunit_ and KUNIT_ prefixes.
- Tested on interessed architectures.
Changes since v4:
- Rebased to v6.15-rc7
- Dropped all code in __report_bug()
- Moved all checks in WARN*() macros.
- Dropped all architecture specific code.
- Made __kunit_is_suppressed_warning nice to noinstr functions.
Changes since v5:
- Rebased to v7.0-rc3
- Added RCU protection for the suppressed warnings list.
- Added static key and branching optimization.
- Removed custom `strcmp` implementation and reworked
__kunit_is_suppressed_warning() entrypoint function.
Changes since v6:
- Moved suppression checks from WARN*() macros to warn_slowpath_fmt()
and __report_bug().
- Replaced stack-allocated suppression struct with kunit_kzalloc() heap
allocation tied to the KUnit test lifecycle.
- Changed suppression strategy from function-name matching to task-scoped:
all warnings on the current task are suppressed between START and END,
rather than only warnings originating from a specific named function.
- Simplified macro API: removed KUNIT_DECLARE_SUPPRESSED_WARNING(),
the START macro now takes (test) and handles allocation internally.
- Removed static key and branching optiomization, as by the time it
was executed, callers are already in warn slowpaths.
- Link to v6: https://lore.kernel.org/r/20260317-kunit_add_support-v6-0-dd22aeb3fe5d@redhat.com
Changes since v7:
- Integrated suppression into existing KUnit hooks infrastructure
- Removed CONFIG_KUNIT_SUPPRESS_BACKTRACE
- Added suppression check in __warn_printk()
- Added spinlock for writer-side RCU protection
- Replaced explicit rcu_read_lock/unlock with guard(rcu)()
- Added scoped API (kunit_warning_suppress) using __cleanup attribute
- Updated DRM patch to use scoped API
- Expanded self-tests: incremental counting, cross-kthread isolation
- Rewrote documentation covering all three API forms with examples
- Link to v7: https://lore.kernel.org/r/20260420-kunit_add_support-v7-0-e8bc6e0f70de@redhat.com
Changes since v8:
- Rebased to v7.1-rc2
- Remove KUNIT_START/END_SUPPRESSED_WARNING() macros
- Add KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT checks to drm tests
- Link to v8: https://lore.kernel.org/r/20260504-kunit_add_support-v8-0-3e5957cdd235@redhat.com
Changes since v9:
- Fix silent false-pass when kunit_start_suppress_warning() returns NULL
- Fix RCU lockdep splat for kunit_is_suppressed_warning() calls
- Move disable_trace_on_warning() in __report_bug()
- Make suppress counter atomic
- Mark helper warn functions in selftest as noinline
- Add kunit_skip() for CONFIG_BUG=n in selftests
- Fix potentially uninitialized data.was_active in kthread seltest
- Add kthread_stop() in kthread selftest early exit
- Initialize scaling_factor to INT_MIN in DRM scaling tests
- Add include for bool in test-bug.h to fix CONFIG_KUNIT=n case
- Link to v9: https://lore.kernel.org/r/20260508-kunit_add_support-v9-0-99df7aa880f6@redhat.com
--
2.34.1
---
To: Brendan Higgins <brendan.higgins@linux.dev>
To: David Gow <david@davidgow.net>
To: Rae Moar <raemoar63@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
To: Paul Walmsley <pjw@kernel.org>
To: Palmer Dabbelt <palmer@dabbelt.com>
To: Albert Ou <aou@eecs.berkeley.edu>
To: Alexandre Ghiti <alex@ghiti.fr>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Maxime Ripard <mripard@kernel.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
To: David Airlie <airlied@gmail.com>
To: Simona Vetter <simona@ffwll.ch>
To: Jonathan Corbet <corbet@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux-kselftest@vger.kernel.org
Cc: kunit-dev@googlegroups.com
Cc: linux-riscv@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: workflows@vger.kernel.org
Cc: linux-doc@vger.kernel.org
---
Alessandro Carminati (1):
bug/kunit: Core support for suppressing warning backtraces
Guenter Roeck (3):
kunit: Add backtrace suppression self-tests
drm: Suppress intentional warning backtraces in scaling unit tests
kunit: Add documentation for warning backtrace suppression API
Documentation/dev-tools/kunit/usage.rst | 46 +++++++-
drivers/gpu/drm/tests/drm_rect_test.c | 32 +++++-
include/kunit/test-bug.h | 26 +++++
include/kunit/test.h | 98 ++++++++++++++++
kernel/panic.c | 11 ++
lib/bug.c | 14 ++-
lib/kunit/Makefile | 4 +-
lib/kunit/backtrace-suppression-test.c | 196 ++++++++++++++++++++++++++++++++
lib/kunit/bug.c | 119 +++++++++++++++++++
lib/kunit/hooks-impl.h | 2 +
10 files changed, 538 insertions(+), 10 deletions(-)
---
base-commit: 74fe02ce122a6103f207d29fafc8b3a53de6abaf
change-id: 20260312-kunit_add_support-2f35806b19dd
Best regards,
--
Albert Esteve <aesteve@redhat.com>
^ permalink raw reply
* Re: [PATCH v8 4/4] kunit: Add documentation for warning backtrace suppression API
From: kernel test robot @ 2026-05-13 6:12 UTC (permalink / raw)
To: Albert Esteve, Arnd Bergmann, Brendan Higgins, David Gow,
Rae Moar, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Jonathan Corbet, Shuah Khan,
Andrew Morton, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti
Cc: oe-kbuild-all, Linux Memory Management List, linux-kernel,
linux-arch, linux-kselftest, kunit-dev, dri-devel, workflows,
linux-riscv, linux-doc, peterz, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter,
Alessandro Carminati
In-Reply-To: <20260504-kunit_add_support-v8-4-3e5957cdd235@redhat.com>
Hi Alessandro,
kernel test robot noticed the following build errors:
[auto build test ERROR on 80234b5ab240f52fa45d201e899e207b9265ef91]
url: https://github.com/intel-lab-lkp/linux/commits/Albert-Esteve/bug-kunit-Core-support-for-suppressing-warning-backtraces/20260513-043807
base: 80234b5ab240f52fa45d201e899e207b9265ef91
patch link: https://lore.kernel.org/r/20260504-kunit_add_support-v8-4-3e5957cdd235%40redhat.com
patch subject: [PATCH v8 4/4] kunit: Add documentation for warning backtrace suppression API
config: x86_64-rhel-9.4-ltp (https://download.01.org/0day-ci/archive/20260513/202605130826.e6Lyyytr-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260513/202605130826.e6Lyyytr-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605130826.e6Lyyytr-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/drm_buddy.c:6:
>> include/kunit/test-bug.h:90:15: error: unknown type name 'bool'
90 | static inline bool kunit_is_suppressed_warning(bool count) { return false; }
| ^~~~
include/kunit/test-bug.h:13:1: note: 'bool' is defined in header '<stdbool.h>'; this is probably fixable by adding '#include <stdbool.h>'
12 | #include <linux/stddef.h> /* for NULL */
+++ |+#include <stdbool.h>
13 |
include/kunit/test-bug.h:90:48: error: unknown type name 'bool'
90 | static inline bool kunit_is_suppressed_warning(bool count) { return false; }
| ^~~~
include/kunit/test-bug.h:90:48: note: 'bool' is defined in header '<stdbool.h>'; this is probably fixable by adding '#include <stdbool.h>'
vim +/bool +90 include/kunit/test-bug.h
88
89 static inline struct kunit *kunit_get_current_test(void) { return NULL; }
> 90 static inline bool kunit_is_suppressed_warning(bool count) { return false; }
91
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Heiko Carstens @ 2026-05-13 5:53 UTC (permalink / raw)
To: Manuel Ebner
Cc: Jani Nikula, andy.shevchenko, apw, corbet, dwaipayanray1, joe,
kees, linux-doc, linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <46d8a5a8c8c77d3de9acfa1c55de2148fb2975c5.camel@mailbox.org>
On Tue, May 12, 2026 at 12:43:54PM +0200, Manuel Ebner wrote:
> On Tue, 2026-05-12 at 11:52 +0300, Jani Nikula wrote:
> > On Sun, 10 May 2026, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > > add strlcat and alternatives
> >
> > You'd think it's the strlcat() definition that needs a comment above it
> > saying it's deprecated. I don't think folks really look at
> > deprecated.rst.
>
> arch/s390/lib/string.c
> lib/string.c
> and
> tools/include/nolibc/string.h
>
> do not mentions anything about obsolete.
>
> include/linux/fortify-string.h has
>
> /* Defined after fortified strlen() to reuse it. */
> extern size_t __real_strlcat(char *p, const char *q, size_t avail) __RENAME(strlcat);
> /**
> * strlcat - Append a string to an existing string
> * [...]
> * Do not use this function. While FORTIFY_SOURCE tries to avoid
> * read and write overflows, this is only possible when the sizes
> * of @p and @q are known to the compiler. Prefer building the
> * string with formatting, via scnprintf(), seq_buf, or similar.
>
> should i add this to the former three files?
I'm going to remove s390's implementation of strlcat(), and convert the only
two users of strlcat() in s390 code to something else. No reason to add a
comment there.
^ permalink raw reply
* Re: [PATCH v3 0/3] Documentation: security-bugs: new updates covering triage and AI
From: Willy Tarreau @ 2026-05-12 19:13 UTC (permalink / raw)
To: Jonathan Corbet
Cc: greg, Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel
In-Reply-To: <871pfgpn2a.fsf@trenco.lwn.net>
On Tue, May 12, 2026 at 11:14:37AM -0600, Jonathan Corbet wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> > This series tries to translate recent discussions on the security list
> > on how to better handle reports. It details:
> > - when not to Cc: the security list
> > - what classes of bugs do not need to be handled privately
> > - minimum requirements for AI-assisted reports
> >
> > As usual, this is probably perfectible but can already help in the short
> > term as we can point it to reporters, so barring any strong disagreement,
> > better continue to proceed in small incremental improvements and observe
> > the effects.
>
> OK, I've applied the series to docs-fixes; after a short exposure in
> linux-next I'll ship it Linusward.
Thank you!
> I have a couple of comments on the individual changes that might merit
> an eventual add-on patch.
Yes, feel free to suggest. I'm not fond of how the pub/priv decision is
stretched into multiple sections and I'd like to rework it to have a
dedicate section "public or private" which describes how to take the
decision then later we can explain whom to contact depending on this
choice. It's not much different from what we have but it would clarify
certain points. So in any case I think I'll propose an update later, so
anything you can propose to improve the situation is more than welcome!
Thanks!
Willy
^ permalink raw reply
* Re: [PATCH v3 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports
From: Jonathan Corbet @ 2026-05-12 17:21 UTC (permalink / raw)
To: Willy Tarreau, greg
Cc: Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel, Willy Tarreau, Greg KH
In-Reply-To: <20260509094755.2838-4-w@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
> AI tools are increasingly used to assist in bug discovery. While these
> tools can identify valid issues, reports that are submitted without
> manual verification often lack context, contain speculative impact
> assessments, or include unnecessary formatting. Such reports increase
> triage effort, waste maintainers' time and may be ignored.
>
> Reports where the reporter has verified the issue and the proposed fix
> typically meet quality standards. This documentation outlines specific
> requirements for length, formatting, and impact evaluation to reduce
> the effort needed to deal with these reports.
>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Leon Romanovsky <leon@kernel.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/security-bugs.rst | 57 +++++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
One nit:
> + * **Impact Evaluation**: Many AI-generated reports lack an understanding of
> + the kernel's threat model and go to great lengths inventing theoretical
> + consequences.
If only we had a shiny new document describing that threat model that we
could reference here... :)
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Jonathan Corbet @ 2026-05-12 17:20 UTC (permalink / raw)
To: Willy Tarreau, greg
Cc: Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel, Willy Tarreau, Greg KH
In-Reply-To: <20260509094755.2838-3-w@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
> The use of automated tools to find bugs in random locations of the kernel
> induces a raise of security reports even if most of them should just be
> reported as regular bugs. This patch is an attempt at drawing a line
> between what qualifies as a security bug and what does not, hoping to
> improve the situation and ease decision on the reporter's side.
>
> It defers the enumeration to a new file, threat-model.rst, that tries
> to enumerate various classes of issues that are and are not security
> bugs. This should permit to more easily update this file for various
> subsystem-specific rules without having to revisit the security bug
> reporting guide.
One thing here:
[...]
> +* **Capability-based protection**:
> +
> + * users not having the ``CAP_SYS_ADMIN`` capability may not alter the
> + kernel's configuration, memory nor state, change other users' view of the
> + file system layout, grant any user capabilities they do not have, nor
> + affect the system's availability (shutdown, reboot, panic, hang, or making
> + the system unresponsive via unbounded resource exhaustion).
That is pretty demonstrably not true, and will likely elicit challenges
at some point. There are a lot of "make me root" capabilities that
enable users to do all of those things; consider CAP_DAC_OVERRIDE as an
obvious example. I think that just about all of the capabilities will
enable at least one of those things - that's why the capabilities exist
in the first place. So I think this needs to be written far more
generally.
As a lower-priority thing, lockdown mode is meant to at least try to
provide some stronger guarantees, and lockdown circumvention seems to be
normally be viewed as a security bug. Worth a mention?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3 0/3] Documentation: security-bugs: new updates covering triage and AI
From: Jonathan Corbet @ 2026-05-12 17:14 UTC (permalink / raw)
To: Willy Tarreau, greg
Cc: Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel, Willy Tarreau
In-Reply-To: <20260509094755.2838-1-w@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
> This series tries to translate recent discussions on the security list
> on how to better handle reports. It details:
> - when not to Cc: the security list
> - what classes of bugs do not need to be handled privately
> - minimum requirements for AI-assisted reports
>
> As usual, this is probably perfectible but can already help in the short
> term as we can point it to reporters, so barring any strong disagreement,
> better continue to proceed in small incremental improvements and observe
> the effects.
OK, I've applied the series to docs-fixes; after a short exposure in
linux-next I'll ship it Linusward.
I have a couple of comments on the individual changes that might merit
an eventual add-on patch.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v9 0/4] kunit: Add support for suppressing warning backtraces
From: Albert Esteve @ 2026-05-12 15:05 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, linux-kernel,
linux-arch, linux-kselftest, kunit-dev, dri-devel, workflows,
linux-riscv, linux-doc, peterz, Alessandro Carminati,
Guenter Roeck, Kees Cook, Linux Kernel Functional Testing,
Maíra Canal, Dan Carpenter, Simona Vetter
In-Reply-To: <20260508165203.1cd1b27e664754d18dbea899@linux-foundation.org>
On Sat, May 9, 2026 at 1:52 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 08 May 2026 17:02:44 +0200 Albert Esteve <aesteve@redhat.com> wrote:
>
> > Some unit tests intentionally trigger warning backtraces by passing bad
> > parameters to kernel API functions. Such unit tests typically check the
> > return value from such calls, not the existence of the warning backtrace.
> >
> > ...
> >
> > Solve the problem by providing a means to suppress warning backtraces
> > originating from the current kthread while executing test code.
> > Since each KUnit test runs in its own kthread, this effectively scopes
> > suppression to the test that enabled it, without requiring any
> > architecture-specific code.
>
> Thanks. AI review has a bunch of questions:
> https://sashiko.dev/#/patchset/20260508-kunit_add_support-v9-0-99df7aa880f6@redhat.com
>
Hi! Most look like valid concerns/issues. I will send a new version
addressing them then, and monitor sashiko to ensure I clear
everything.
Thanks for the link.
BR,
Albert.
^ permalink raw reply
* Re: [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: David Laight @ 2026-05-12 13:57 UTC (permalink / raw)
To: Manuel Ebner
Cc: Jani Nikula, andy.shevchenko, apw, corbet, dwaipayanray1, joe,
kees, linux-doc, linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <46d8a5a8c8c77d3de9acfa1c55de2148fb2975c5.camel@mailbox.org>
On Tue, 12 May 2026 12:43:54 +0200
Manuel Ebner <manuelebner@mailbox.org> wrote:
> On Tue, 2026-05-12 at 11:52 +0300, Jani Nikula wrote:
> > On Sun, 10 May 2026, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > > add strlcat and alternatives
> >
> > You'd think it's the strlcat() definition that needs a comment above it
> > saying it's deprecated. I don't think folks really look at
> > deprecated.rst.
>
> arch/s390/lib/string.c
> lib/string.c
> and
> tools/include/nolibc/string.h
>
> do not mentions anything about obsolete.
>
> include/linux/fortify-string.h has
>
> /* Defined after fortified strlen() to reuse it. */
> extern size_t __real_strlcat(char *p, const char *q, size_t avail) __RENAME(strlcat);
> /**
> * strlcat - Append a string to an existing string
> * [...]
> * Do not use this function. While FORTIFY_SOURCE tries to avoid
> * read and write overflows, this is only possible when the sizes
> * of @p and @q are known to the compiler. Prefer building the
> * string with formatting, via scnprintf(), seq_buf, or similar.
I'm not that advice is really that good.
The other schemes (esp scnprintf) are just as dangerous.
If the code has just done 'buf = kmalloc(size)' then strlcat(,,size)
is fine - from an overflow point of view.
strlcat() isn't really any worse than memcpy().
(unlike strncat() which was just an accident waiting to happen)
-- David
>
> should i add this to the former three files?
>
> Manuel
>
> >
> > BR,
> > Jani.
> >
> > >
> > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > > ---
> > > Documentation/process/deprecated.rst | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> > > index fed56864d036..b8a65c19796c 100644
> > > --- a/Documentation/process/deprecated.rst
> > > +++ b/Documentation/process/deprecated.rst
> > > @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is
> > > strscpy(),
> > > though care must be given to any cases where the return value of strlcpy()
> > > is used, since strscpy() will return negative errno values when it truncates.
> > >
> > > +strlcat()
> > > +---------
> > > +strlcat() must re-scan the destination string from the beginning on each
> > > +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> > > +snprintf() and scnprintf()
> > > +
> > > %p format specifier
> > > -------------------
> > > Traditionally, using "%p" in format strings would lead to regular address
> >
>
>
^ permalink raw reply
* Re: [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Manuel Ebner @ 2026-05-12 10:43 UTC (permalink / raw)
To: Jani Nikula
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <748c2c3d549740918e14f29aa25dd475b99c1313@intel.com>
On Tue, 2026-05-12 at 11:52 +0300, Jani Nikula wrote:
> On Sun, 10 May 2026, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > add strlcat and alternatives
>
> You'd think it's the strlcat() definition that needs a comment above it
> saying it's deprecated. I don't think folks really look at
> deprecated.rst.
arch/s390/lib/string.c
lib/string.c
and
tools/include/nolibc/string.h
do not mentions anything about obsolete.
include/linux/fortify-string.h has
/* Defined after fortified strlen() to reuse it. */
extern size_t __real_strlcat(char *p, const char *q, size_t avail) __RENAME(strlcat);
/**
* strlcat - Append a string to an existing string
* [...]
* Do not use this function. While FORTIFY_SOURCE tries to avoid
* read and write overflows, this is only possible when the sizes
* of @p and @q are known to the compiler. Prefer building the
* string with formatting, via scnprintf(), seq_buf, or similar.
should i add this to the former three files?
Manuel
>
> BR,
> Jani.
>
> >
> > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > ---
> > Documentation/process/deprecated.rst | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> > index fed56864d036..b8a65c19796c 100644
> > --- a/Documentation/process/deprecated.rst
> > +++ b/Documentation/process/deprecated.rst
> > @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is
> > strscpy(),
> > though care must be given to any cases where the return value of strlcpy()
> > is used, since strscpy() will return negative errno values when it truncates.
> >
> > +strlcat()
> > +---------
> > +strlcat() must re-scan the destination string from the beginning on each
> > +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> > +snprintf() and scnprintf()
> > +
> > %p format specifier
> > -------------------
> > Traditionally, using "%p" in format strings would lead to regular address
>
^ permalink raw reply
* Re: [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Jani Nikula @ 2026-05-12 8:52 UTC (permalink / raw)
To: Manuel Ebner, manuelebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510165451.57674-2-manuelebner@mailbox.org>
On Sun, 10 May 2026, Manuel Ebner <manuelebner@mailbox.org> wrote:
> add strlcat and alternatives
You'd think it's the strlcat() definition that needs a comment above it
saying it's deprecated. I don't think folks really look at
deprecated.rst.
BR,
Jani.
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> Documentation/process/deprecated.rst | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> index fed56864d036..b8a65c19796c 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> though care must be given to any cases where the return value of strlcpy()
> is used, since strscpy() will return negative errno values when it truncates.
>
> +strlcat()
> +---------
> +strlcat() must re-scan the destination string from the beginning on each
> +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> +snprintf() and scnprintf()
> +
> %p format specifier
> -------------------
> Traditionally, using "%p" in format strings would lead to regular address
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH 2/2] scripts: checkpatch.pl: add warning for strlcat()
From: Manuel Ebner @ 2026-05-12 7:36 UTC (permalink / raw)
To: David Laight, Jonathan Corbet
Cc: andy.shevchenko, apw, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260511142745.7757b1b2@pumpkin>
On Mon, 2026-05-11 at 14:27 +0100, David Laight wrote:
> On Mon, 11 May 2026 06:12:36 -0600
> Jonathan Corbet <corbet@lwn.net> wrote:
>
> > Manuel Ebner <manuelebner@mailbox.org> writes:
> >
> > > add a warning for strlcat()
> > >
> > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > > ---
> > > scripts/checkpatch.pl | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > > index 0492d6afc9a1..ca1a8e67d529 100755
> > > --- a/scripts/checkpatch.pl
> > > +++ b/scripts/checkpatch.pl
> > > @@ -7085,6 +7085,12 @@ sub process {
> > > "Prefer strscpy over strlcpy - see:
> > > https://github.com/KSPP/linux/issues/89\n" . $herecurr);
Here you can see the external urls already deployed. there are two more in
the code blocks above.
> > > }
> > >
> > > +# strlcat uses that should likely be
> > > + if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
> > > + WARN("STRLCAT",
> > > + "Prefer seq_buf_printf() over strlcat - see:
> > > https://github.com/KSPP/linux/issues/370\n" . $herecurr);
> > > + }
> >
> > Using seq_buf_printf() requires switching over to the seq_buf API in
> > general, it is not just a simple substitution, so this advice may prove
> > unhelpful to many.
>
> And I'm not sure the external url is a good idea.
It wasn't my idea originally. but I'm open to suggestions.
Manuel
> >
> > jon
> >
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-12 5:54 UTC (permalink / raw)
To: Greg KH
Cc: Jonathan Corbet, Leon Romanovsky, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <2026051220-fetal-obituary-bb2b@gregkh>
On Tue, May 12, 2026 at 07:46:34AM +0200, Greg KH wrote:
> On Mon, May 11, 2026 at 02:42:14PM -0600, Jonathan Corbet wrote:
> > Willy Tarreau <w@1wt.eu> writes:
> >
> > >> I can ship stuff Linusward quickly too... :) But it's fine if Greg
> > >> takes it, of course.
> > >
> > > Oh that's fine then. I thought you only delivered such updates into next
> > > releases. I'm fine with either way of course! Let's pick the path of
> > > least effort for each.
> >
> > That's my normal procedure, since there are few docs changes that have
> > greater urgency, but I do have a "fixes" branch.
> >
> > Greg, what's your preference? Unless I hear otherwise, I guess I'll
> > apply it shortly.
>
> Please apply it and take it through your tree, thanks!
Thanks to you both!
Willy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox