* Re: [PATCH 6/9] kernel/api: add API specification for sys_close
From: Greg Kroah-Hartman @ 2026-03-13 15:52 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E. McKenney, Jonathan Corbet, Dmitry Vyukov, Randy Dunlap,
Cyril Hrubis, Kees Cook, Jake Edge, David Laight, Askar Safin,
Gabriele Paoloni, Mauro Carvalho Chehab, Christian Brauner,
Alexander Viro, Andrew Morton, Masahiro Yamada, Shuah Khan,
Ingo Molnar, Arnd Bergmann
In-Reply-To: <20260313150928.2637368-7-sashal@kernel.org>
On Fri, Mar 13, 2026 at 11:09:16AM -0400, Sasha Levin wrote:
> + * notes: This syscall has subtle non-POSIX semantics: the fd is ALWAYS closed
> + * regardless of the return value. POSIX specifies that on EINTR, the state
> + * of the fd is unspecified, but Linux always closes it. HP-UX requires
> + * retrying close() on EINTR, but doing so on Linux may close an unrelated
> + * fd that was reassigned by another thread. For portable code, the safest
> + * approach is to check for errors but never retry close().
We don't care about HP-UX :)
> + * Error codes from the flush callback (EIO, ENOSPC, EDQUOT) indicate that
> + * previously written data may have been lost. These errors are particularly
> + * common on NFS where write errors are often deferred to close time.
What flush callback?
> + *
> + * The driver's release() callback errors are explicitly ignored by the
> + * kernel, so device driver cleanup errors are not propagated to userspace.
What "The driver" here? release() callbacks aren't really relevant
here.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/9] kernel/api: add debugfs interface for kernel API specifications
From: Sasha Levin @ 2026-03-13 16:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E. McKenney, Jonathan Corbet, Dmitry Vyukov, Randy Dunlap,
Cyril Hrubis, Kees Cook, Jake Edge, David Laight, Askar Safin,
Gabriele Paoloni, Mauro Carvalho Chehab, Christian Brauner,
Alexander Viro, Andrew Morton, Masahiro Yamada, Shuah Khan,
Ingo Molnar, Arnd Bergmann
In-Reply-To: <2026031301-duplicate-finalist-b7a5@gregkh>
On Fri, Mar 13, 2026 at 04:32:23PM +0100, Greg Kroah-Hartman wrote:
>On Fri, Mar 13, 2026 at 11:09:13AM -0400, Sasha Levin wrote:
>> Add a debugfs interface to expose kernel API specifications at runtime.
>> This allows tools and users to query the complete API specifications
>> through the debugfs filesystem.
>>
>> The interface provides:
>> - /sys/kernel/debug/kapi/list - lists all available API specifications
>> - /sys/kernel/debug/kapi/specs/<name> - detailed info for each API
>>
>> Each specification file includes:
>> - Function name, version, and descriptions
>> - Execution context requirements and flags
>> - Parameter details with types, flags, and constraints
>> - Return value specifications and success conditions
>> - Error codes with descriptions and conditions
>> - Locking requirements and constraints
>> - Signal handling specifications
>> - Examples, notes, and deprecation status
>>
>> This enables runtime introspection of kernel APIs for documentation
>> tools, static analyzers, and debugging purposes.
>>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> ---
>> Documentation/dev-tools/kernel-api-spec.rst | 88 ++--
>
>You are removing stuff from the file you created earlier in this patch
>series, is that ok?
Sorry, just a rebasing artifact from shuffling patches around. I'll fix it.
>> --- /dev/null
>> +++ b/kernel/api/kapi_debugfs.c
>> @@ -0,0 +1,503 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Kernel API specification debugfs interface
>> + *
>> + * This provides a debugfs interface to expose kernel API specifications
>> + * at runtime, allowing tools and users to query the complete API specs.
>> + */
>
>No copyright line? :)
I'll add one.
>And this is, a totally and crazy interface with debugfs, I love it!
Thanks :)
>Two minor minor nits:
>
>> +static int __init kapi_debugfs_init(void)
>> +{
>> + struct kernel_api_spec *spec;
>> + struct dentry *spec_dir;
>> +
>> + /* Create main directory */
>> + kapi_debugfs_root = debugfs_create_dir("kapi", NULL);
>> +
>> + /* Create list file */
>> + debugfs_create_file("list", 0444, kapi_debugfs_root, NULL, &kapi_list_fops);
>> +
>> + /* Create specs subdirectory */
>> + spec_dir = debugfs_create_dir("specs", kapi_debugfs_root);
>> +
>> + /* Create a file for each API spec */
>> + for (spec = __start_kapi_specs; spec < __stop_kapi_specs; spec++) {
>> + debugfs_create_file(spec->name, 0444, spec_dir, spec, &kapi_spec_fops);
>> + }
>
>No need for { }
ack
>> +
>> + pr_info("Kernel API debugfs interface initialized\n");
>
>When code is working properly, it should be quiet, no need for this as
>initializing this can not fail.
ack
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 5/9] kernel/api: add API specification for sys_open
From: Sasha Levin @ 2026-03-13 16:42 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E. McKenney, Jonathan Corbet, Dmitry Vyukov, Randy Dunlap,
Cyril Hrubis, Kees Cook, Jake Edge, David Laight, Askar Safin,
Gabriele Paoloni, Mauro Carvalho Chehab, Christian Brauner,
Alexander Viro, Andrew Morton, Masahiro Yamada, Shuah Khan,
Ingo Molnar, Arnd Bergmann
In-Reply-To: <2026031343-raft-panhandle-0a21@gregkh>
On Fri, Mar 13, 2026 at 04:33:57PM +0100, Greg Kroah-Hartman wrote:
>On Fri, Mar 13, 2026 at 11:09:15AM -0400, Sasha Levin wrote:
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>No changelog?
I'll add something to all patches.
>> + * since-version: 1.0
>
>I think since older versions :)
Right. I guess that in my mind 1.0 was the first official "release". I'll
update it to 0.01.
>Anyway, very nice documentation, will be good to have this as part of
>the kerneldocs no matter what the result of this patch series is.
Thanks!
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 6/9] kernel/api: add API specification for sys_close
From: Sasha Levin @ 2026-03-13 16:46 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E. McKenney, Jonathan Corbet, Dmitry Vyukov, Randy Dunlap,
Cyril Hrubis, Kees Cook, Jake Edge, David Laight, Askar Safin,
Gabriele Paoloni, Mauro Carvalho Chehab, Christian Brauner,
Alexander Viro, Andrew Morton, Masahiro Yamada, Shuah Khan,
Ingo Molnar, Arnd Bergmann
In-Reply-To: <2026031348-deceiving-calculate-0017@gregkh>
On Fri, Mar 13, 2026 at 04:49:28PM +0100, Greg Kroah-Hartman wrote:
>On Fri, Mar 13, 2026 at 11:09:16AM -0400, Sasha Levin wrote:
>> + * Calling close() on a file descriptor while another thread is using it
>> + * (e.g., in a blocking read() or write()) has implementation-defined
>> + * behavior. On Linux, the blocked operation continues on the underlying
>> + * file and may complete even after close() returns.
>
>I'm guessing this came from the man pages? This is Linux, so we are the
>"implementation" here :)
Right :)
I was just trying to make it a comparison to posix. I'll clarify the docs here.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 6/9] kernel/api: add API specification for sys_close
From: Sasha Levin @ 2026-03-13 16:55 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E. McKenney, Jonathan Corbet, Dmitry Vyukov, Randy Dunlap,
Cyril Hrubis, Kees Cook, Jake Edge, David Laight, Askar Safin,
Gabriele Paoloni, Mauro Carvalho Chehab, Christian Brauner,
Alexander Viro, Andrew Morton, Masahiro Yamada, Shuah Khan,
Ingo Molnar, Arnd Bergmann
In-Reply-To: <2026031321-steadfast-fang-ba42@gregkh>
On Fri, Mar 13, 2026 at 04:52:30PM +0100, Greg Kroah-Hartman wrote:
>On Fri, Mar 13, 2026 at 11:09:16AM -0400, Sasha Levin wrote:
>> + * notes: This syscall has subtle non-POSIX semantics: the fd is ALWAYS closed
>> + * regardless of the return value. POSIX specifies that on EINTR, the state
>> + * of the fd is unspecified, but Linux always closes it. HP-UX requires
>> + * retrying close() on EINTR, but doing so on Linux may close an unrelated
>> + * fd that was reassigned by another thread. For portable code, the safest
>> + * approach is to check for errors but never retry close().
>
>We don't care about HP-UX :)
Fair :) The original text was contrasting Linux's "always closed" behavior
with HP-UX. I'll just drop that reference.
>> + * Error codes from the flush callback (EIO, ENOSPC, EDQUOT) indicate that
>> + * previously written data may have been lost. These errors are particularly
>> + * common on NFS where write errors are often deferred to close time.
>
>What flush callback?
This was referring to f_op->flush, which filp_flush() calls during close.
But you're right, that's internal plumbing. I'll reworded to describe the
behavior without referencing internal callbacks:
Error codes like EIO, ENOSPC, and EDQUOT indicate that previously
buffered writes may have failed to reach storage.
>> + *
>> + * The driver's release() callback errors are explicitly ignored by the
>> + * kernel, so device driver cleanup errors are not propagated to userspace.
>
>What "The driver" here? release() callbacks aren't really relevant
>here.
The original text was noting that __fput() ignores the return value of
f_op->release(), so even if a driver's cleanup fails, userspace never
sees it via close(). But agreed, that's an internal implementation detail
not relevant to the syscall specification. Removed.
Thanks for the review!
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 0/9] Kernel API Specification Framework
From: Jakub Kicinski @ 2026-03-14 18:18 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E. McKenney, Greg Kroah-Hartman, Jonathan Corbet,
Dmitry Vyukov, Randy Dunlap, Cyril Hrubis, Kees Cook, Jake Edge,
David Laight, Askar Safin, Gabriele Paoloni,
Mauro Carvalho Chehab, Christian Brauner, Alexander Viro,
Andrew Morton, Masahiro Yamada, Shuah Khan, Ingo Molnar,
Arnd Bergmann
In-Reply-To: <20260313150928.2637368-1-sashal@kernel.org>
On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
> This enables static analysis tools to verify userspace API usage at compile
> time, test generation based on formal specifications, consistent error handling
> validation, automated documentation generation, and formal verification of
> kernel interfaces.
Could you give some examples? We have machine readable descriptions for
Netlink interfaces, we approached syzbot folks and they did not really
seem to care for those.
^ permalink raw reply
* Re: [PATCH 0/9] Kernel API Specification Framework
From: David Laight @ 2026-03-14 22:44 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Sasha Levin, linux-api, linux-kernel, linux-doc, linux-fsdevel,
linux-kbuild, linux-kselftest, workflows, tools, x86,
Thomas Gleixner, Paul E. McKenney, Greg Kroah-Hartman,
Jonathan Corbet, Dmitry Vyukov, Randy Dunlap, Cyril Hrubis,
Kees Cook, Jake Edge, Askar Safin, Gabriele Paoloni,
Mauro Carvalho Chehab, Christian Brauner, Alexander Viro,
Andrew Morton, Masahiro Yamada, Shuah Khan, Ingo Molnar,
Arnd Bergmann
In-Reply-To: <20260314111822.63a2ba4a@kernel.org>
On Sat, 14 Mar 2026 11:18:22 -0700
Jakub Kicinski <kuba@kernel.org> wrote:
> On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
> > This enables static analysis tools to verify userspace API usage at compile
> > time, test generation based on formal specifications, consistent error handling
> > validation, automated documentation generation, and formal verification of
> > kernel interfaces.
>
> Could you give some examples? We have machine readable descriptions for
> Netlink interfaces, we approached syzbot folks and they did not really
> seem to care for those.
The whole thing reminds me of doxygen comment blocks.
They tend to make it hard to read the source files, hard to search
the source files (due to all the extra matches) and are pretty much
always out of date.
The kerndoc comment blocks for trivial helper functions are hard enough
to keep up to date.
The only way even parameter descriptions are going to stay correct is if the
compiler is using the definition and only the comment part is extra.
For error returns you'll need the documentation to be at the return site.
David
^ permalink raw reply
* Re: [PATCH 0/9] Kernel API Specification Framework
From: Sasha Levin @ 2026-03-15 6:36 UTC (permalink / raw)
To: Jakub Kicinski
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E. McKenney, Greg Kroah-Hartman, Jonathan Corbet,
Dmitry Vyukov, Randy Dunlap, Cyril Hrubis, Kees Cook, Jake Edge,
David Laight, Askar Safin, Gabriele Paoloni,
Mauro Carvalho Chehab, Christian Brauner, Alexander Viro,
Andrew Morton, Masahiro Yamada, Shuah Khan, Ingo Molnar,
Arnd Bergmann
In-Reply-To: <20260314111822.63a2ba4a@kernel.org>
On Sat, Mar 14, 2026 at 11:18:22AM -0700, Jakub Kicinski wrote:
>On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
>> This enables static analysis tools to verify userspace API usage at compile
>> time, test generation based on formal specifications, consistent error handling
>> validation, automated documentation generation, and formal verification of
>> kernel interfaces.
>
>Could you give some examples? We have machine readable descriptions for
>Netlink interfaces, we approached syzbot folks and they did not really
>seem to care for those.
Once the API is in a machine-readable format, we can write formatters to
output whatever downstream tools need. The kapi tool in the series
already ships with plain text, JSON, and RST formatters, and adding new
output formats is straightforward. We don't need to convince the
syzkaller folks to consume our specs, we can just output them in a
format that syzkaller already understands.
For example, I have a syzlang formatter that produces the following
from the sys_read spec in this series:
# --- read ---
# Read data from a file descriptor
#
# @context process, sleepable
#
# @capability CAP_DAC_OVERRIDE: Bypass discretionary access control on read permission
# @capability CAP_DAC_READ_SEARCH: Bypass read permission checks on regular files
#
# @error EPERM (-1): Returned by fanotify permission events...
# @error EINTR (-4): The call was interrupted by a signal before any data was read.
# @error EIO (-5): A low-level I/O error occurred.
# @error EBADF (-9): fd is not a valid file descriptor, or fd was not opened for reading.
# @error EAGAIN (-11): O_NONBLOCK set and read would block.
# @error EACCES (-13): LSM denied the read operation via security_file_permission().
# @error EFAULT (-14): buf points outside the accessible address space.
# @error EISDIR (-21): fd refers to a directory.
# @error EINVAL (-22): fd not suitable for reading, O_DIRECT misaligned, count negative...
# @error ENODATA (-61): Data not available in cache...
# @error EOVERFLOW (-75): File position plus count would exceed LLONG_MAX.
# @error EOPNOTSUPP (-95): Read not supported for this file type...
# @error ENOBUFS (-105): Buffer too small for complete notification...
#
# @constraint MAX_RW_COUNT: actual_count = min(count, MAX_RW_COUNT)
# @constraint File must be open for reading: (file->f_mode & FMODE_READ) && (file->f_mode & FMODE_CAN_READ)
#
# @signal Any signal: restartable, error=-4
#
# @lock file->f_pos_lock (mutex, internal): For seekable files with FMODE_ATOMIC_POS
# @lock Filesystem-specific locks (rwlock, internal)
# @lock RCU read-side (rwlock, internal): File descriptor lookup protection
#
# @side-effect file->f_pos: f_pos advanced by bytes read [conditional, irreversible]
# @side-effect inode access time: atime updated unless O_NOATIME [conditional, irreversible]
# @side-effect task I/O accounting: rchar and syscr updated [conditional, irreversible]
# @side-effect fsnotify events: FS_ACCESS event generated [conditional, irreversible]
#
# @return ssize_t: bytes read on success, negative errno on error
#
read(fd fd, buf ptr[out, buffer[out]], count len[buf]) intptr
That said, I don't have a strong end-to-end example with the 4 syscalls
proposed here, as open/close/read/write don't take complex structures,
and the subsystems underneath them aren't specced yet. The value becomes
clearer with richer interfaces where the gap between "we know the type
signature" and "we know the full behavioral contract" is much wider.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 0/9] Kernel API Specification Framework
From: Sasha Levin @ 2026-03-15 6:46 UTC (permalink / raw)
To: David Laight
Cc: Jakub Kicinski, linux-api, linux-kernel, linux-doc, linux-fsdevel,
linux-kbuild, linux-kselftest, workflows, tools, x86,
Thomas Gleixner, Paul E. McKenney, Greg Kroah-Hartman,
Jonathan Corbet, Dmitry Vyukov, Randy Dunlap, Cyril Hrubis,
Kees Cook, Jake Edge, Askar Safin, Gabriele Paoloni,
Mauro Carvalho Chehab, Christian Brauner, Alexander Viro,
Andrew Morton, Masahiro Yamada, Shuah Khan, Ingo Molnar,
Arnd Bergmann
In-Reply-To: <20260314224435.35465615@pumpkin>
On Sat, Mar 14, 2026 at 10:44:35PM +0000, David Laight wrote:
>On Sat, 14 Mar 2026 11:18:22 -0700
>Jakub Kicinski <kuba@kernel.org> wrote:
>
>> On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
>> > This enables static analysis tools to verify userspace API usage at compile
>> > time, test generation based on formal specifications, consistent error handling
>> > validation, automated documentation generation, and formal verification of
>> > kernel interfaces.
>>
>> Could you give some examples? We have machine readable descriptions for
>> Netlink interfaces, we approached syzbot folks and they did not really
>> seem to care for those.
>
>The whole thing reminds me of doxygen comment blocks.
>They tend to make it hard to read the source files, hard to search
>the source files (due to all the extra matches) and are pretty much
>always out of date.
>
>The kerndoc comment blocks for trivial helper functions are hard enough
>to keep up to date.
>
>The only way even parameter descriptions are going to stay correct is if the
>compiler is using the definition and only the comment part is extra.
>For error returns you'll need the documentation to be at the return site.
When CONFIG_KAPI_RUNTIME_CHECKS is enabled, the specs are enforced at
the syscall boundary. The SYSCALL_DEFINEx macro grows a wrapper that
calls kapi_validate_syscall_params() before the real implementation and
kapi_validate_syscall_return() after it. Parameter constraints (ranges,
valid flag masks, alignment) are checked on every syscall entry, and
return values are validated against the documented success/error ranges
on every exit.
If a spec goes stale, it has runtime consequences. A new flag bit added
without updating the spec's valid_mask means callers using that flag get
EINVAL, which any test exercising that path catches immediately. An
implementation returning an undocumented error code triggers a warning
from the return validation.
The selftest in the series (tools/testing/selftests/kapi/test_kapi.c)
exercises this with real syscalls, both valid and invalid inputs,
verifying the validation layer catches violations.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v2 00/25] Introduce meminspect
From: Bjorn Andersson @ 2026-03-16 2:24 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Jonathan Corbet, Shuah Khan, Eugen Hristev, Arnd Bergmann,
Dennis Zhou, Tejun Heo, Christoph Lameter, Andrew Morton,
Thomas Gleixner, Peter Zijlstra, Anna-Maria Behnsen,
Frederic Weisbecker, Ingo Molnar, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Kees Cook, Brendan Jackman,
Johannes Weiner, Zi Yan, Chris Li, Kairui Song, Kemeng Shi,
Nhat Pham, Baoquan He, Barry Song, Youngjun Park, Petr Mladek,
John Ogness, Sergey Senozhatsky, Mathieu Poirier, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
workflows, linux-doc, linux-kernel, linux-arch, linux-mm,
linux-arm-msm, linux-remoteproc, devicetree
In-Reply-To: <20260311-minidump-v2-v2-0-f91cedc6f99e@oss.qualcomm.com>
On Wed, Mar 11, 2026 at 01:45:44AM +0530, Mukesh Ojha wrote:
> First of all, I want to thank Eugene for his excellent work on this
> series. What began as the Qualcomm Minidump driver from me has now
> evolved into meminspect. He also presented meminspect a few months ago
> at Linux Plumbers 2025.
>
> Video of the recording is available here for anyone interested:
> https://www.youtube.com/watch?v=aDZv4-kOLSc
>
> Introduction:
>
> meminspect is a mechanism which allows the kernel to mark specific
> memory areas for memory dumping or specific inspection, statistics,
> usage. Once regions are marked, meminspect keeps an internal list with
> the regions in a dedicated table. Further, these regions can be
> accessed using specific API by any interested driver. Regions being
> marked beforehand, when the system is up and running, there is no need
> nor dependency on a panic handler, or a working kernel that can dump the
> debug information. meminspect can be primarily used for debugging. The
> approach is feasible to work when pstore, kdump, or another mechanism do
> not. Pstore relies on persistent storage, a dedicated RAM area or
> flash, which has the disadvantage of having the memory reserved all the
> time, or another specific non volatile memory. Some devices cannot keep
> the RAM contents on reboot so ramoops does not work. Some devices do not
> allow kexec to run another kernel to debug the crashed one. For such
> devices, that have another mechanism to help debugging, like firmware,
> kmemdump is a viable solution.
>
> meminspect can create a core image, similar with /proc/vmcore, with only
> the registered regions included. This can be loaded into crash tool/gdb
> and analyzed. This happens if CRASH_DUMP=y. To have this working,
> specific information from the kernel is registered, and this is done at
> meminspect init time, no need for the meminspect users to do anything.
>
> This version of the meminspect patch series includes two drivers that
> make use of it: one is the Qualcomm Minidump, and the other one is the
> Debug Kinfo backend for Android devices, reworked from this source here:
> https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/drivers/android/debug_kinfo.c
> written originally by Jone Chou <jonechou@google.com>
>
> *** History, motivation and available online resources ***
>
> The patch series is based on both minidump and kmemdump previous implementations.
>
> After the three RFC kmemdump versions, considering the ML discussions, it was decided to
> move this into kernel/ directory and rework it into naming it meminspect, as Thomas Gleixner
> suggested.
>
> Initial version of kmemdump and discussion is available here:
> https://lore.kernel.org/lkml/20250422113156.575971-1-eugen.hristev@linaro.org/
>
> Kmemdump has been presented and discussed at Linaro Connect 2025,
> including motivation, scope, usability and feasability.
> Video of the recording is available here for anyone interested:
> https://www.youtube.com/watch?v=r4gII7MX9zQ&list=PLKZSArYQptsODycGiE0XZdVovzAwYNwtK&index=14
>
> Linaro blog on kmemdump can be found here:
> https://www.linaro.org/blog/introduction-to-kmemdump/
>
> Linaro blog on kmemdump step by stem using minidump backend is available here:
> https://www.linaro.org/blog/kmemdump-step-by-step-on-qualcomm-automotive-platform/
>
> The implementation is based on the initial Pstore/directly mapped zones
> published as an RFC here:
> https://lore.kernel.org/all/20250217101706.2104498-1-eugen.hristev@linaro.org/
>
> The back-end implementation for qcom_minidump is based on the minidump
> patch series and driver written by Mukesh Ojha, thanks:
> https://lore.kernel.org/lkml/20240131110837.14218-1-quic_mojha@quicinc.com/
>
> The RFC v2 version with .section creation and macro annotation kmemdump
> is available here:
> https://lore.kernel.org/all/20250724135512.518487-1-eugen.hristev@linaro.org/
>
> The RFC v3 version with making everything static, which was pretty much rejected due to
> all reasons discussed on the public ML:
> https://lore.kernel.org/all/20250912150855.2901211-1-eugen.hristev@linaro.org/
>
> *** How to use meminspect with minidump backend on Qualcomm platform guide ***
>
> Prerequisites:
> Crash tool compiled with target=ARM64 and minor changes required for
> usual crash mode (minimal mode works without the patch) **A patch can be
> applied from here https://p.calebs.dev/1687bc ** This patch will be
> eventually sent in a reworked way to crash tool.
>
That patch was written 8 months ago, what's the timeline for landing
this?
It's not feasible to have every users rebuild crash from source and
maintain this copy in order to use the tool.
> Target kernel must be built with : CONFIG_DEBUG_INFO_REDUCED=n ; this
> will have vmlinux include all the debugging information needed for crash
> tool.
>
> Also, the kernel requires these as well: CONFIG_MEMINSPECT,
> CONFIG_CRASH_DUMP and the driver CONFIG_QCOM_MINIDUMP
>
> Kernel arguments: Kernel firmware must be set to mode 'mini' by kernel
> module parameter like this : qcom_scm.download_mode=mini
>
> After the kernel boots, and minidump module is loaded, everything is
> ready for a possible crash.
>
> Once the crash happens, the firmware will kick in and you will see on
> the console the message saying Sahara init, etc, that the firmware is
> waiting in download mode. (this is subject to firmware supporting this
> mode, I am using sa8775p-ride board)
>
> Example of log on the console:
> "
> [...]
> B - 1096414 - usb: init start
> B - 1100287 - usb: qusb_dci_platform , 0x19
> B - 1105686 - usb: usb3phy: PRIM success: lane_A , 0x60
> B - 1107455 - usb: usb2phy: PRIM success , 0x4
> B - 1112670 - usb: dci, chgr_type_det_err
> B - 1117154 - usb: ID:0x260, value: 0x4
> B - 1121942 - usb: ID:0x108, value: 0x1d90
> B - 1124992 - usb: timer_start , 0x4c4b40
> B - 1129140 - usb: vbus_det_pm_unavail
> B - 1133136 - usb: ID:0x252, value: 0x4
> B - 1148874 - usb: SUPER , 0x900e
> B - 1275510 - usb: SUPER , 0x900e
> B - 1388970 - usb: ID:0x20d, value: 0x0
> B - 1411113 - usb: ENUM success
> B - 1411113 - Sahara Init
> B - 1414285 - Sahara Open
> "
This doesn't add any specific value, it's just "Device entered ramdump
mode".
>
> Once the board is in download mode, you can use the qdl tool (I
> personally use edl , have not tried qdl yet)
Is this your or Eugen's comment? Why haven't you tested qdl yet?
>, to get all the regions as
> separate files. The tool from the host computer will list the regions
> in the order they were downloaded.
>
> Once you have all the files simply use `cat` to put them all together,
> in the order of the indexes. For my kernel config and setup, here is my
> cat command : (you can use a script or something, I haven't done that so
> far):
So these need to be sorted in numerical order, by that number at the end
of the file name?
Do you manually punch these in? How do we make this user friendly?
Regards,
Bjorn
>
> `cat md_KELF1.BIN md_Kvmcorein2.BIN md_Kconfig3.BIN \
> md_Ktotalram4.BIN md_Kcpu_poss5.BIN md_Kcpu_pres6.BIN \
> md_Kcpu_onli7.BIN md_Kcpu_acti8.BIN md_Kmem_sect9.BIN \
> md_Kjiffies10.BIN md_Klinux_ba11.BIN md_Knr_threa12.BIN \
> md_Knr_irqs13.BIN md_Ktainted_14.BIN md_Ktaint_fl15.BIN \
> md_Knode_sta16.BIN md_K__per_cp17.BIN md_Knr_swapf18.BIN \
> md_Kinit_uts19.BIN md_Kprintk_r20.BIN md_Kprintk_r21.BIN \
> md_Kprb22.BIN md_Kprb_desc23.BIN md_Kprb_info24.BIN \
> md_Kprb_data25.BIN md_Khigh_mem26.BIN md_Kinit_mm27.BIN \
> md_Kunknown29.BIN md_Kunknown30.BIN md_Kunknown31.BIN \
> md_Kunknown32.BIN md_Kunknown33.BIN md_Kunknown34.BIN \
> md_Kunknown35.BIN md_Kunknown37.BIN \
> md_Kunknown38.BIN md_Kunknown39.BIN md_Kunknown40.BIN \
> md_Kunknown41.BIN md_Kunknown42.BIN md_Kunknown43.BIN \
> md_Kunknown44.BIN md_Kunknown45.BIN md_Kunknown46.BIN \
> md_Kunknown47.BIN md_Kunknown48.BIN md_Kunknown49.BIN \
> md_Kunknown50.BIN md_Kunknown51.BIN md_Kunknown52.BIN \
> md_Kunknown53.BIN md_Kunknown54.BIN > ./minidump_image`
>
> Once you have the resulted file, use `crash` tool to load it, like this:
> `./crash --no_modules --no_panic --no_kmem_cache --zero_excluded vmlinux minidump_image`
>
> There is also a --minimal mode for ./crash that would work without any patch applied
> to crash tool, but you can't inspect symbols, etc.
>
> Once you load crash you will see something like this :
> KERNEL: minidump/20260310-235110/vmlinux [TAINTED]
> DUMPFILE: ./minidump/20260310-235110/minidump_image
> CPUS: 8 [OFFLINE: 7]
> DATE: Thu Jan 1 05:30:00 +0530 1970
> UPTIME: 00:00:27
> TASKS: 0
> NODENAME: qemuarm64
> RELEASE: 7.0.0-rc3-next-20260309-00028-g528b3c656121
> VERSION: #5 SMP PREEMPT Tue Mar 10 18:18:41 UTC 2026
> MACHINE: aarch64 (unknown Mhz)
> MEMORY: 0
> PANIC: "Kernel panic - not syncing: sysrq triggered crash"
>
> crash> log
> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x514f0014]
> [ 0.000000] Linux version 7.0.0-rc3-next-20260309-00028-g528b3c656121 (@21e3bca4168f) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #5 SMP PREEMPT Tue Mar 10 18:18:41 UTC 2026
>
> *** Debug Kinfo backend driver ***
> I need help with the testing of this driver, Anyone who actually wants
> to test this, feel free to reply to the patch. we have also written a
> simple DT binding for the driver.
>
> Thanks in advance for the review, and apologies if I missed addressing any comment.
>
> -Mukesh
>
> Changes in v2: https://lore.kernel.org/lkml/20251119154427.1033475-1-eugen.hristev@linaro.org/
> - Fixed doc warnings
> - Fixed kernel-test robot warnings.
> - Took Mike suggestion to remove mark inspect flag for dynamic memory.
> - Added R-b for printk patch.
> - Modified some commit messages for clarity.
> - corrected binding change for debug-kinfo as per Rob suggestion.
>
> Changelog for meminspect v1:
> - rename to meminspect
> - start on top of v2 actually, with the section and all.
> - remove the backend thing, change the API to access the table
> - move everything to kernel/
> - add dependency to CRASH_DUMP instead of a separate knob
> - move the minidump driver to soc/qcom
> - integrate the meminspect better into memblock by using a new memblock flag
> - minor fixes : use dev_err_probe everywhere, rearrange variable declarations,
> remove some useless code, etc.
>
> Changelog for RFC v3:
> - V2 available here : https://lore.kernel.org/all/20250724135512.518487-1-eugen.hristev@linaro.org/
> - Removed the .section as requested by David Hildenbrand.
> - Moved all kmemdump registration(when possible) to vmcoreinfo.
> - Because of this, some of the variables that I was registering had to be non-static
> so I had to modify this as per David Hildenbrand suggestion.
> - Fixed minor things in the Kinfo driver: one field was broken, fixed some
> compiler warnings, fixed the copyright and remove some useless includes.
> - Moved the whole kmemdump from drivers/debug into mm/ and Kconfigs into mm/Kconfig.debug
> and it's now available in kernel hacking, as per Randy Dunlap review
> - Reworked some of the Documentation as per review from Jon Corbet
>
> Changelog for RFC v2:
> - V1 available here: https://lore.kernel.org/lkml/20250422113156.575971-1-eugen.hristev@linaro.org/
> - Reworked the whole minidump implementation based on suggestions from Thomas Gleixner.
> This means new API, macros, new way to store the regions inside kmemdump
> (ditched the IDR, moved to static allocation, have a static default backend, etc)
> - Reworked qcom_minidump driver based on review from Bjorn Andersson
> - Reworked printk log buffer registration based on review from Petr Mladek
>
> I appologize if I missed any review comments.
> Patches are sent on top on next-20260309 tag
>
> ---
> Eugen Hristev (21):
> kernel: Introduce meminspect
> init/version: Annotate static information into meminspect
> mm/percpu: Annotate static information into meminspect
> cpu: Annotate static information into meminspect
> genirq/irqdesc: Annotate static information into meminspect
> timers: Annotate static information into meminspect
> kernel/fork: Annotate static information into meminspect
> mm/page_alloc: Annotate static information into meminspect
> mm/show_mem: Annotate static information into meminspect
> mm/swapfile: Annotate static information into meminspect
> kernel/vmcore_info: Register dynamic information into meminspect
> kernel/configs: Register dynamic information into meminspect
> mm/init-mm: Annotate static information into meminspect
> panic: Annotate static information into meminspect
> kallsyms: Annotate static information into meminspect
> mm/mm_init: Annotate static information into meminspect
> sched/core: Annotate runqueues into meminspect
> remoteproc: qcom: Move minidump data structures into its own header
> soc: qcom: Add minidump backend driver
> soc: qcom: smem: Add minidump platform device
> meminspect: Add debug kinfo compatible driver
>
> Mukesh Ojha (4):
> mm/numa: Register node data information into meminspect
> mm/sparse: Register information into meminspect
> printk: Register information into meminspect
> dt-bindings: reserved-memory: Add Google Kinfo Pixel reserved memory
>
> Documentation/dev-tools/index.rst | 1 +
> Documentation/dev-tools/meminspect.rst | 144 +++++++
> .../bindings/reserved-memory/google,kinfo.yaml | 46 ++
> MAINTAINERS | 14 +
> drivers/of/platform.c | 1 +
> drivers/remoteproc/qcom_common.c | 56 +--
> drivers/soc/qcom/Kconfig | 13 +
> drivers/soc/qcom/Makefile | 1 +
> drivers/soc/qcom/minidump.c | 272 ++++++++++++
> drivers/soc/qcom/smem.c | 10 +
> include/asm-generic/vmlinux.lds.h | 13 +
> include/linux/meminspect.h | 263 ++++++++++++
> include/linux/soc/qcom/minidump.h | 72 ++++
> init/Kconfig | 1 +
> init/version-timestamp.c | 3 +
> init/version.c | 3 +
> kernel/Makefile | 1 +
> kernel/configs.c | 6 +
> kernel/cpu.c | 5 +
> kernel/fork.c | 3 +
> kernel/irq/irqdesc.c | 2 +
> kernel/kallsyms.c | 9 +
> kernel/meminspect/Kconfig | 30 ++
> kernel/meminspect/Makefile | 4 +
> kernel/meminspect/kinfo.c | 284 +++++++++++++
> kernel/meminspect/meminspect.c | 471 +++++++++++++++++++++
> kernel/panic.c | 4 +
> kernel/printk/printk.c | 11 +
> kernel/sched/core.c | 2 +
> kernel/time/timer.c | 2 +
> kernel/vmcore_info.c | 4 +
> mm/init-mm.c | 11 +
> mm/mm_init.c | 2 +
> mm/numa.c | 2 +
> mm/page_alloc.c | 2 +
> mm/percpu.c | 2 +
> mm/show_mem.c | 2 +
> mm/sparse.c | 6 +
> mm/swapfile.c | 2 +
> 39 files changed, 1725 insertions(+), 55 deletions(-)
> ---
> base-commit: 343f51842f4ed7143872f3aa116a214a5619a4b9
> change-id: 20260311-minidump-v2-eed8da647ce5
>
> Best regards,
> --
> -Mukesh Ojha
>
^ permalink raw reply
* Re: [PATCH 0/9] Kernel API Specification Framework
From: Dmitry Vyukov @ 2026-03-16 7:05 UTC (permalink / raw)
To: Jakub Kicinski, syzkaller
Cc: Sasha Levin, linux-api, linux-kernel, linux-doc, linux-fsdevel,
linux-kbuild, linux-kselftest, workflows, tools, x86,
Thomas Gleixner, Paul E. McKenney, Greg Kroah-Hartman,
Jonathan Corbet, Randy Dunlap, Cyril Hrubis, Kees Cook, Jake Edge,
David Laight, Askar Safin, Gabriele Paoloni,
Mauro Carvalho Chehab, Christian Brauner, Alexander Viro,
Andrew Morton, Masahiro Yamada, Shuah Khan, Ingo Molnar,
Arnd Bergmann
In-Reply-To: <20260314111822.63a2ba4a@kernel.org>
On Sat, 14 Mar 2026 at 19:18, Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
> > This enables static analysis tools to verify userspace API usage at compile
> > time, test generation based on formal specifications, consistent error handling
> > validation, automated documentation generation, and formal verification of
> > kernel interfaces.
>
> Could you give some examples? We have machine readable descriptions for
> Netlink interfaces, we approached syzbot folks and they did not really
> seem to care for those.
I think our reasoning wrt syzkaller was that not all interfaces in all
relevant kernels are described with netlink yml descriptions, so we
need to continue using the extraction of interfaces from the source
code. And if we have that code, then using yml as an additional data
source only adds code/complexity. Additionally, we may extract some
extra constraints/info from code that are not present in yml.
Realistically system call descriptions may have the same problem for
us at this point, since we extract lots of info from the source code
already:
https://raw.githubusercontent.com/google/syzkaller/refs/heads/master/sys/linux/auto.txt
(and LLMs obviously can allow us to extract more)
^ permalink raw reply
* Re: [PATCH v2 01/25] kernel: Introduce meminspect
From: Mukesh Ojha @ 2026-03-16 8:31 UTC (permalink / raw)
To: Randy Dunlap
Cc: Jonathan Corbet, Shuah Khan, Eugen Hristev, Arnd Bergmann,
Dennis Zhou, Tejun Heo, Christoph Lameter, Andrew Morton,
Thomas Gleixner, Peter Zijlstra, Anna-Maria Behnsen,
Frederic Weisbecker, Ingo Molnar, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Kees Cook, Brendan Jackman,
Johannes Weiner, Zi Yan, Chris Li, Kairui Song, Kemeng Shi,
Nhat Pham, Baoquan He, Barry Song, Youngjun Park, Petr Mladek,
John Ogness, Sergey Senozhatsky, Bjorn Andersson, Mathieu Poirier,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, workflows, linux-doc, linux-kernel, linux-arch,
linux-mm, linux-arm-msm, linux-remoteproc, devicetree
In-Reply-To: <e398475e-4db2-40ed-baeb-89c2bbf6a0d5@infradead.org>
On Wed, Mar 11, 2026 at 09:46:57PM -0700, Randy Dunlap wrote:
>
>
> On 3/10/26 1:15 PM, Mukesh Ojha wrote:
> > diff --git a/Documentation/dev-tools/meminspect.rst b/Documentation/dev-tools/meminspect.rst
> > new file mode 100644
> > index 000000000000..d0c7222bdcd7
> > --- /dev/null
> > +++ b/Documentation/dev-tools/meminspect.rst
> > @@ -0,0 +1,144 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +==========
> > +meminspect
> > +==========
> > +
> > +This document provides information about the meminspect feature.
> > +
> > +Overview
> > +========
> > +
> > +meminspect is a mechanism that allows the kernel to register a chunk of
> > +memory into a table, to be used at a later time for a specific
> > +inspection purpose like debugging, memory dumping or statistics.
> > +
> > +meminspect allows drivers to traverse the inspection table on demand,
> > +or to register a notifier to be called whenever a new entry is being added
>
> preferably... is added
>
> > +or removed.
> > +
> > +The reasoning for meminspect is also to minimize the required information
> > +in case of a kernel problem. For example a traditional debug method involves
> > +dumping the whole kernel memory and then inspecting it. Meminspect allows the
> > +users to select which memory is of interest, in order to help this specific
> > +use case in production, where memory and connectivity are limited.
> > +
> > +Although the kernel has multiple internal mechanisms, meminspect fits
> > +a particular model which is not covered by the others.
> > +
> > +meminspect Internals
> > +====================
> > +
> > +API
> > +---
> > +
> > +Static memory can be registered at compile time, by instructing the compiler
> > +to create a separate section with annotation info.
> > +For each such annotated memory (variables usually), a dedicated struct
> > +is being created with the required information.
>
> is created
>
> > +To achieve this goal, some basic APIs are available:
> > +
> > +* MEMINSPECT_ENTRY(idx, sym, sz)
> > + is the basic macro that takes an ID, the symbol, and a size.
> > +
> > +To make it easier, some wrappers are also defined
> > +
> > +* MEMINSPECT_SIMPLE_ENTRY(sym)
> > + will use the dedicated MEMINSPECT_ID_##sym with a size equal to sizeof(sym)
>
> uses the dedicated
>
> > +
> > +* MEMINSPECT_NAMED_ENTRY(name, sym)
> > + will be a simple entry that has an id that cannot be derived from the sym,
>
> is a simple entry that
>
> > + so a name has to be provided
> > +
> > +* MEMINSPECT_AREA_ENTRY(sym, sz)
> > + this will register sym, but with the size given as sz, useful for e.g.
>
> registers sym, but with
>
> > + arrays which do not have a fixed size at compile time.
> > +
> > +For dynamically allocated memory, or for other cases, the following APIs
> > +are being defined::
>
> are defined::
>
> > +
> > + meminspect_register_id_pa(enum meminspect_uid id, phys_addr_t zone,
> > + size_t size, unsigned int type);
> > +
> > +which takes the ID and the physical address.
> > +
> > +Similarly there are variations:
> > +
> > + * meminspect_register_pa() omits the ID
> > + * meminspect_register_id_va() requires the ID but takes a virtual address
> > + * meminspect_register_va() omits the ID and requires a virtual address
> > +
> > +If the ID is not given, the next avialable dynamic ID is allocated.
>
> available
>
> > +
> > +To unregister a dynamic entry, some APIs are being defined:
>
> are defined:
>
> > + * meminspect_unregister_pa(phys_addr_t zone, size_t size);
> > + * meminspect_unregister_id(enum meminspect_uid id);
> > + * meminspect_unregister_va(va, size);
> > +
> > +All of the above have a lock variant that ensures the lock on the table
> > +is taken.
> > +
> > +
> > +meminspect drivers
> > +------------------
> > +
> > +Drivers are free to traverse the table by using a dedicated function::
> > +
> > + meminspect_traverse(void *priv, MEMINSPECT_ITERATOR_CB cb)
> > +
> > +The callback will be called for each entry in the table.
>
> maybe is called
>
> > +
> > +Drivers can also register a notifier with meminspect_notifier_register()
> > +and unregister with meminspect_notifier_unregister() to be called when a new
> > +entry is being added or removed.
>
> is added or removed.
>
> > +
> > +Data structures
> > +---------------
> > +
> > +The regions are being stored in a simple fixed size array. It avoids
>
> are stored
>
> > +memory allocation overhead. This is not performance critical nor does
> > +allocating a few hundred entries create a memory consumption problem.
> > +
> > +The static variables registered into meminspect are being annotated into
>
> are annotated into
>
> > +a dedicated .inspect_table memory section. This is then walked by meminspect> +at a later time and each variable is then copied to the whole inspect table.
> > +
> > +meminspect Initialization
> > +-------------------------
> > +
> > +At any time, meminspect will be ready to accept region registration
>
> meminspect is ready
>
> > +from any part of the kernel. The table does not require any initialization.
> > +In case CONFIG_CRASH_DUMP is enabled, meminspect will create an ELF header
>
> meminspect creates an ELF header
>
> > +corresponding to a core dump image, in which each region is added as a
> > +program header. In this scenario, the first region is this ELF header, and
> > +the second region is the vmcoreinfo ELF note.
> > +By using this mechanism, all the meminspect table, if dumped, can be
> > +concatenated to obtain a core image that is loadable with the `crash` tool.
> > +
> > +meminspect example
> > +==================
> > +
> > +A simple scenario for meminspect is the following:
> > +The kernel registers the linux_banner variable into meminspect with
> > +a simple annotation like::
> > +
> > + MEMINSPECT_SIMPLE_ENTRY(linux_banner);
> > +
> > +The meminspect late initcall will parse the compilation time created table
>
> maybe... compile-time
>
> > +and copy the entry information into the inspection table.
> > +At a later point, any interested driver can call the traverse function to
> > +find out all entries in the table.
> > +A specific driver will then note into a specific table the address of the
> > +banner and the size of it.
> > +The specific table is then written to a shared memory area that can be
> > +read by upper level firmware.
> > +When the kernel freezes (hypothetically), the kernel will no longer feed
> > +the watchdog. The watchdog will trigger a higher exception level interrupt
> > +which will be handled by the upper level firmware. This firmware will then
> > +read the shared memory table and find an entry with the start and size of
> > +the banner. It will then copy it for debugging purpose. The upper level
> > +firmware will then be able to provide useful debugging information,
> > +like in this example, the banner.
> > +
> > +As seen here, meminspect facilitates the interaction between the kernel
> > +and a specific firmware.
Thanks for your time and review, I have applied the changes to both doc. and
Kconfig for next version.
>
>
> --
> ~Randy
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v2 20/25] printk: Register information into meminspect
From: John Ogness @ 2026-03-16 9:39 UTC (permalink / raw)
To: Mukesh Ojha, Jonathan Corbet, Shuah Khan, Eugen Hristev,
Arnd Bergmann, Dennis Zhou, Tejun Heo, Christoph Lameter,
Andrew Morton, Thomas Gleixner, Peter Zijlstra,
Anna-Maria Behnsen, Frederic Weisbecker, Ingo Molnar, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Kees Cook, Brendan Jackman,
Johannes Weiner, Zi Yan, Chris Li, Kairui Song, Kemeng Shi,
Nhat Pham, Baoquan He, Barry Song, Youngjun Park, Petr Mladek,
Sergey Senozhatsky, Bjorn Andersson, Mathieu Poirier,
Konrad Dybcio, Mukesh Ojha, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Saravana Kannan
Cc: workflows, linux-doc, linux-kernel, linux-arch, linux-mm,
linux-arm-msm, linux-remoteproc, devicetree
In-Reply-To: <20260311-minidump-v2-v2-20-f91cedc6f99e@oss.qualcomm.com>
On 2026-03-11, Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> wrote:
> Annotate vital static, dynamic information into meminspect for debugging
>
> Static:
> - prb_descs
> - prb_infos
> - prb
> - prb_data
> - printk_rb_static
> - printk_rb_dynamic
FYI: vmcore also exports the symbol "clear_seq". It is not required if
you are interested in reading _everything_ in the buffer. But it may be
interesting if you want to mirror vmcore tool features.
> Dynamic:
> - new_descs
> - new_infos
> - new_log_buf
>
> meminspect uses a different API to annotate variables for inspection,
> and information about these variables is stored in the inspection table.
>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> Co-developed-by: Eugen Hristev <eugen.hristev@linaro.org>
> Signed-off-by: Eugen Hristev <eugen.hristev@linaro.org>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Reviewed-by: John Ogness <john.ogness@linutronix.de>
^ permalink raw reply
* Re: [PATCH v2 20/25] printk: Register information into meminspect
From: Eugen Hristev @ 2026-03-16 10:24 UTC (permalink / raw)
To: John Ogness, Mukesh Ojha, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Dennis Zhou, Tejun Heo, Christoph Lameter,
Andrew Morton, Thomas Gleixner, Peter Zijlstra,
Anna-Maria Behnsen, Frederic Weisbecker, Ingo Molnar, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Kees Cook, Brendan Jackman,
Johannes Weiner, Zi Yan, Chris Li, Kairui Song, Kemeng Shi,
Nhat Pham, Baoquan He, Barry Song, Youngjun Park, Petr Mladek,
Sergey Senozhatsky, Bjorn Andersson, Mathieu Poirier,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan
Cc: workflows, linux-doc, linux-kernel, linux-arch, linux-mm,
linux-arm-msm, linux-remoteproc, devicetree
In-Reply-To: <87pl54f70l.fsf@jogness.linutronix.de>
On 3/16/26 11:39, John Ogness wrote:
> On 2026-03-11, Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> wrote:
>> Annotate vital static, dynamic information into meminspect for debugging
>>
>> Static:
>> - prb_descs
>> - prb_infos
>> - prb
>> - prb_data
>> - printk_rb_static
>> - printk_rb_dynamic
>
> FYI: vmcore also exports the symbol "clear_seq". It is not required if
> you are interested in reading _everything_ in the buffer. But it may be
> interesting if you want to mirror vmcore tool features.
Thank you for your review and suggestion. One of the key points of
meminspect is to be easy to use by the kernel developer. E.g. to be easy
to add another symbol, like `clear_seq` for a particular use case.
So, someone wanting to make use of it, can easily add it.
The purpose of the initial submission would be to have a basic use case
working, and show it as an example for everyone.
If you would like to detail about the features you mention, it could be
interesting to try them and see if it would work with a meminspect dump.
Eugen
>
>> Dynamic:
>> - new_descs
>> - new_infos
>> - new_log_buf
>>
>> meminspect uses a different API to annotate variables for inspection,
>> and information about these variables is stored in the inspection table.
>>
>> Reviewed-by: Petr Mladek <pmladek@suse.com>
>> Co-developed-by: Eugen Hristev <eugen.hristev@linaro.org>
>> Signed-off-by: Eugen Hristev <eugen.hristev@linaro.org>
>> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
>
> Reviewed-by: John Ogness <john.ogness@linutronix.de>
^ permalink raw reply
* Re: [PATCH v2 24/25] dt-bindings: reserved-memory: Add Google Kinfo Pixel reserved memory
From: Mukesh Ojha @ 2026-03-16 11:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jonathan Corbet, Shuah Khan, Eugen Hristev, Arnd Bergmann,
Dennis Zhou, Tejun Heo, Christoph Lameter, Andrew Morton,
Thomas Gleixner, Peter Zijlstra, Anna-Maria Behnsen,
Frederic Weisbecker, Ingo Molnar, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Kees Cook, Brendan Jackman,
Johannes Weiner, Zi Yan, Chris Li, Kairui Song, Kemeng Shi,
Nhat Pham, Baoquan He, Barry Song, Youngjun Park, Petr Mladek,
John Ogness, Sergey Senozhatsky, Bjorn Andersson, Mathieu Poirier,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, workflows, linux-doc, linux-kernel, linux-arch,
linux-mm, linux-arm-msm, linux-remoteproc, devicetree
In-Reply-To: <20260311-light-terrestrial-bison-d9cd97@quoll>
On Wed, Mar 11, 2026 at 10:05:55AM +0100, Krzysztof Kozlowski wrote:
> On Wed, Mar 11, 2026 at 01:46:08AM +0530, Mukesh Ojha wrote:
> > Add documentation for Google Kinfo Pixel reserved memory area.
> >
> > Co-developed-by: Eugen Hristev <eugen.hristev@linaro.org>
> > Signed-off-by: Eugen Hristev <eugen.hristev@linaro.org>
> > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > ---
> > .../bindings/reserved-memory/google,kinfo.yaml | 46 ++++++++++++++++++++++
> > MAINTAINERS | 6 +++
> > 2 files changed, 52 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/reserved-memory/google,kinfo.yaml b/Documentation/devicetree/bindings/reserved-memory/google,kinfo.yaml
> > new file mode 100644
> > index 000000000000..2f964151f0c0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/reserved-memory/google,kinfo.yaml
>
> Nothing improved, read previous feedback.
Missed it, will need to fix this as per compatible name..
>
> > @@ -0,0 +1,46 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/reserved-memory/google,kinfo.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Google Pixel Kinfo reserved memory
> > +
> > +maintainers:
> > + - Eugen Hristev <eugen.hristev@linaro.org>
> > + - Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > +
> > +description: |
>
> Do not need '|' unless you need to preserve formatting.
>
> > + This binding represents reserved-memory used to store data for firmware/bootloader
>
> Nothing improved.
Will reword it.
>
> > + on the Pixel platform. The stored data is debugging information of the running
> > + kernel.
> > +
> > +allOf:
> > + - $ref: reserved-memory.yaml
> > +
> > +properties:
> > + compatible:
> > + const: google,debug-kinfo
> > +
> > + reg:
> > + description: page-aligned region of memory containing debugging data of running kernel
>
> Missing constraints.
>
> Please wrap code according to the preferred limit expressed in Kernel
> coding style (checkpatch is not a coding style description, but only a
> tool). However don't wrap blindly (see Kernel coding style).
Sure., will fix this as well.
>
> Best regards,
> Krzysztof
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v2 00/25] Introduce meminspect
From: Mukesh Ojha @ 2026-03-16 18:16 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Jonathan Corbet, Shuah Khan, Eugen Hristev, Arnd Bergmann,
Dennis Zhou, Tejun Heo, Christoph Lameter, Andrew Morton,
Thomas Gleixner, Peter Zijlstra, Anna-Maria Behnsen,
Frederic Weisbecker, Ingo Molnar, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Kees Cook, Brendan Jackman,
Johannes Weiner, Zi Yan, Chris Li, Kairui Song, Kemeng Shi,
Nhat Pham, Baoquan He, Barry Song, Youngjun Park, Petr Mladek,
John Ogness, Sergey Senozhatsky, Mathieu Poirier, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
workflows, linux-doc, linux-kernel, linux-arch, linux-mm,
linux-arm-msm, linux-remoteproc, devicetree
In-Reply-To: <abdnp90cC5PI9wyz@baldur>
On Sun, Mar 15, 2026 at 09:24:39PM -0500, Bjorn Andersson wrote:
> On Wed, Mar 11, 2026 at 01:45:44AM +0530, Mukesh Ojha wrote:
> > First of all, I want to thank Eugene for his excellent work on this
> > series. What began as the Qualcomm Minidump driver from me has now
> > evolved into meminspect. He also presented meminspect a few months ago
> > at Linux Plumbers 2025.
> >
> > Video of the recording is available here for anyone interested:
> > https://www.youtube.com/watch?v=aDZv4-kOLSc
> >
> > Introduction:
> >
> > meminspect is a mechanism which allows the kernel to mark specific
> > memory areas for memory dumping or specific inspection, statistics,
> > usage. Once regions are marked, meminspect keeps an internal list with
> > the regions in a dedicated table. Further, these regions can be
> > accessed using specific API by any interested driver. Regions being
> > marked beforehand, when the system is up and running, there is no need
> > nor dependency on a panic handler, or a working kernel that can dump the
> > debug information. meminspect can be primarily used for debugging. The
> > approach is feasible to work when pstore, kdump, or another mechanism do
> > not. Pstore relies on persistent storage, a dedicated RAM area or
> > flash, which has the disadvantage of having the memory reserved all the
> > time, or another specific non volatile memory. Some devices cannot keep
> > the RAM contents on reboot so ramoops does not work. Some devices do not
> > allow kexec to run another kernel to debug the crashed one. For such
> > devices, that have another mechanism to help debugging, like firmware,
> > kmemdump is a viable solution.
> >
> > meminspect can create a core image, similar with /proc/vmcore, with only
> > the registered regions included. This can be loaded into crash tool/gdb
> > and analyzed. This happens if CRASH_DUMP=y. To have this working,
> > specific information from the kernel is registered, and this is done at
> > meminspect init time, no need for the meminspect users to do anything.
> >
> > This version of the meminspect patch series includes two drivers that
> > make use of it: one is the Qualcomm Minidump, and the other one is the
> > Debug Kinfo backend for Android devices, reworked from this source here:
> > https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/drivers/android/debug_kinfo.c
> > written originally by Jone Chou <jonechou@google.com>
> >
> > *** History, motivation and available online resources ***
> >
> > The patch series is based on both minidump and kmemdump previous implementations.
> >
> > After the three RFC kmemdump versions, considering the ML discussions, it was decided to
> > move this into kernel/ directory and rework it into naming it meminspect, as Thomas Gleixner
> > suggested.
> >
> > Initial version of kmemdump and discussion is available here:
> > https://lore.kernel.org/lkml/20250422113156.575971-1-eugen.hristev@linaro.org/
> >
> > Kmemdump has been presented and discussed at Linaro Connect 2025,
> > including motivation, scope, usability and feasability.
> > Video of the recording is available here for anyone interested:
> > https://www.youtube.com/watch?v=r4gII7MX9zQ&list=PLKZSArYQptsODycGiE0XZdVovzAwYNwtK&index=14
> >
> > Linaro blog on kmemdump can be found here:
> > https://www.linaro.org/blog/introduction-to-kmemdump/
> >
> > Linaro blog on kmemdump step by stem using minidump backend is available here:
> > https://www.linaro.org/blog/kmemdump-step-by-step-on-qualcomm-automotive-platform/
> >
> > The implementation is based on the initial Pstore/directly mapped zones
> > published as an RFC here:
> > https://lore.kernel.org/all/20250217101706.2104498-1-eugen.hristev@linaro.org/
> >
> > The back-end implementation for qcom_minidump is based on the minidump
> > patch series and driver written by Mukesh Ojha, thanks:
> > https://lore.kernel.org/lkml/20240131110837.14218-1-quic_mojha@quicinc.com/
> >
> > The RFC v2 version with .section creation and macro annotation kmemdump
> > is available here:
> > https://lore.kernel.org/all/20250724135512.518487-1-eugen.hristev@linaro.org/
> >
> > The RFC v3 version with making everything static, which was pretty much rejected due to
> > all reasons discussed on the public ML:
> > https://lore.kernel.org/all/20250912150855.2901211-1-eugen.hristev@linaro.org/
> >
> > *** How to use meminspect with minidump backend on Qualcomm platform guide ***
> >
> > Prerequisites:
> > Crash tool compiled with target=ARM64 and minor changes required for
> > usual crash mode (minimal mode works without the patch) **A patch can be
> > applied from here https://p.calebs.dev/1687bc ** This patch will be
> > eventually sent in a reworked way to crash tool.
> >
>
> That patch was written 8 months ago, what's the timeline for landing
> this?
>
> It's not feasible to have every users rebuild crash from source and
> maintain this copy in order to use the tool.
Right, Let me see what I can do to make it acceptable..
>
> > Target kernel must be built with : CONFIG_DEBUG_INFO_REDUCED=n ; this
> > will have vmlinux include all the debugging information needed for crash
> > tool.
> >
> > Also, the kernel requires these as well: CONFIG_MEMINSPECT,
> > CONFIG_CRASH_DUMP and the driver CONFIG_QCOM_MINIDUMP
> >
> > Kernel arguments: Kernel firmware must be set to mode 'mini' by kernel
> > module parameter like this : qcom_scm.download_mode=mini
> >
> > After the kernel boots, and minidump module is loaded, everything is
> > ready for a possible crash.
> >
> > Once the crash happens, the firmware will kick in and you will see on
> > the console the message saying Sahara init, etc, that the firmware is
> > waiting in download mode. (this is subject to firmware supporting this
> > mode, I am using sa8775p-ride board)
> >
> > Example of log on the console:
> > "
> > [...]
> > B - 1096414 - usb: init start
> > B - 1100287 - usb: qusb_dci_platform , 0x19
> > B - 1105686 - usb: usb3phy: PRIM success: lane_A , 0x60
> > B - 1107455 - usb: usb2phy: PRIM success , 0x4
> > B - 1112670 - usb: dci, chgr_type_det_err
> > B - 1117154 - usb: ID:0x260, value: 0x4
> > B - 1121942 - usb: ID:0x108, value: 0x1d90
> > B - 1124992 - usb: timer_start , 0x4c4b40
> > B - 1129140 - usb: vbus_det_pm_unavail
> > B - 1133136 - usb: ID:0x252, value: 0x4
> > B - 1148874 - usb: SUPER , 0x900e
> > B - 1275510 - usb: SUPER , 0x900e
> > B - 1388970 - usb: ID:0x20d, value: 0x0
> > B - 1411113 - usb: ENUM success
> > B - 1411113 - Sahara Init
> > B - 1414285 - Sahara Open
> > "
>
> This doesn't add any specific value, it's just "Device entered ramdump
> mode".
Sure, will remove it.
>
> >
> > Once the board is in download mode, you can use the qdl tool (I
> > personally use edl , have not tried qdl yet)
>
> Is this your or Eugen's comment? Why haven't you tested qdl yet?
It was Eugene's comment, but I get it, I can try QDL and check, if it
works.
>
> >, to get all the regions as
> > separate files. The tool from the host computer will list the regions
> > in the order they were downloaded.
> >
> > Once you have all the files simply use `cat` to put them all together,
> > in the order of the indexes. For my kernel config and setup, here is my
> > cat command : (you can use a script or something, I haven't done that so
> > far):
>
> So these need to be sorted in numerical order, by that number at the end
> of the file name?
>
> Do you manually punch these in? How do we make this user friendly?
Yes, manually.. but I think we can do better. We could make
this more user‑friendly by using the section header and string table in
the md_KELF binary both of which existed in the earlier implementation.
Then, we can write an upstream‑friendly script that reads this KELF
metadata file, checks whether a binary with the registered name is
present, and stitches everything together to form a complete ELF that
the crash tool can consume. Let me know if you have any suggestion..
>
> Regards,
> Bjorn
>
> >
> > `cat md_KELF1.BIN md_Kvmcorein2.BIN md_Kconfig3.BIN \
> > md_Ktotalram4.BIN md_Kcpu_poss5.BIN md_Kcpu_pres6.BIN \
> > md_Kcpu_onli7.BIN md_Kcpu_acti8.BIN md_Kmem_sect9.BIN \
> > md_Kjiffies10.BIN md_Klinux_ba11.BIN md_Knr_threa12.BIN \
> > md_Knr_irqs13.BIN md_Ktainted_14.BIN md_Ktaint_fl15.BIN \
> > md_Knode_sta16.BIN md_K__per_cp17.BIN md_Knr_swapf18.BIN \
> > md_Kinit_uts19.BIN md_Kprintk_r20.BIN md_Kprintk_r21.BIN \
> > md_Kprb22.BIN md_Kprb_desc23.BIN md_Kprb_info24.BIN \
> > md_Kprb_data25.BIN md_Khigh_mem26.BIN md_Kinit_mm27.BIN \
> > md_Kunknown29.BIN md_Kunknown30.BIN md_Kunknown31.BIN \
> > md_Kunknown32.BIN md_Kunknown33.BIN md_Kunknown34.BIN \
> > md_Kunknown35.BIN md_Kunknown37.BIN \
> > md_Kunknown38.BIN md_Kunknown39.BIN md_Kunknown40.BIN \
> > md_Kunknown41.BIN md_Kunknown42.BIN md_Kunknown43.BIN \
> > md_Kunknown44.BIN md_Kunknown45.BIN md_Kunknown46.BIN \
> > md_Kunknown47.BIN md_Kunknown48.BIN md_Kunknown49.BIN \
> > md_Kunknown50.BIN md_Kunknown51.BIN md_Kunknown52.BIN \
> > md_Kunknown53.BIN md_Kunknown54.BIN > ./minidump_image`
> >
> > Once you have the resulted file, use `crash` tool to load it, like this:
> > `./crash --no_modules --no_panic --no_kmem_cache --zero_excluded vmlinux minidump_image`
> >
> > There is also a --minimal mode for ./crash that would work without any patch applied
> > to crash tool, but you can't inspect symbols, etc.
> >
> > Once you load crash you will see something like this :
> > KERNEL: minidump/20260310-235110/vmlinux [TAINTED]
> > DUMPFILE: ./minidump/20260310-235110/minidump_image
> > CPUS: 8 [OFFLINE: 7]
> > DATE: Thu Jan 1 05:30:00 +0530 1970
> > UPTIME: 00:00:27
> > TASKS: 0
> > NODENAME: qemuarm64
> > RELEASE: 7.0.0-rc3-next-20260309-00028-g528b3c656121
> > VERSION: #5 SMP PREEMPT Tue Mar 10 18:18:41 UTC 2026
> > MACHINE: aarch64 (unknown Mhz)
> > MEMORY: 0
> > PANIC: "Kernel panic - not syncing: sysrq triggered crash"
> >
> > crash> log
> > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x514f0014]
> > [ 0.000000] Linux version 7.0.0-rc3-next-20260309-00028-g528b3c656121 (@21e3bca4168f) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #5 SMP PREEMPT Tue Mar 10 18:18:41 UTC 2026
> >
> > *** Debug Kinfo backend driver ***
> > I need help with the testing of this driver, Anyone who actually wants
> > to test this, feel free to reply to the patch. we have also written a
> > simple DT binding for the driver.
> >
> > Thanks in advance for the review, and apologies if I missed addressing any comment.
> >
> > -Mukesh
> >
> > Changes in v2: https://lore.kernel.org/lkml/20251119154427.1033475-1-eugen.hristev@linaro.org/
> > - Fixed doc warnings
> > - Fixed kernel-test robot warnings.
> > - Took Mike suggestion to remove mark inspect flag for dynamic memory.
> > - Added R-b for printk patch.
> > - Modified some commit messages for clarity.
> > - corrected binding change for debug-kinfo as per Rob suggestion.
> >
> > Changelog for meminspect v1:
> > - rename to meminspect
> > - start on top of v2 actually, with the section and all.
> > - remove the backend thing, change the API to access the table
> > - move everything to kernel/
> > - add dependency to CRASH_DUMP instead of a separate knob
> > - move the minidump driver to soc/qcom
> > - integrate the meminspect better into memblock by using a new memblock flag
> > - minor fixes : use dev_err_probe everywhere, rearrange variable declarations,
> > remove some useless code, etc.
> >
> > Changelog for RFC v3:
> > - V2 available here : https://lore.kernel.org/all/20250724135512.518487-1-eugen.hristev@linaro.org/
> > - Removed the .section as requested by David Hildenbrand.
> > - Moved all kmemdump registration(when possible) to vmcoreinfo.
> > - Because of this, some of the variables that I was registering had to be non-static
> > so I had to modify this as per David Hildenbrand suggestion.
> > - Fixed minor things in the Kinfo driver: one field was broken, fixed some
> > compiler warnings, fixed the copyright and remove some useless includes.
> > - Moved the whole kmemdump from drivers/debug into mm/ and Kconfigs into mm/Kconfig.debug
> > and it's now available in kernel hacking, as per Randy Dunlap review
> > - Reworked some of the Documentation as per review from Jon Corbet
> >
> > Changelog for RFC v2:
> > - V1 available here: https://lore.kernel.org/lkml/20250422113156.575971-1-eugen.hristev@linaro.org/
> > - Reworked the whole minidump implementation based on suggestions from Thomas Gleixner.
> > This means new API, macros, new way to store the regions inside kmemdump
> > (ditched the IDR, moved to static allocation, have a static default backend, etc)
> > - Reworked qcom_minidump driver based on review from Bjorn Andersson
> > - Reworked printk log buffer registration based on review from Petr Mladek
> >
> > I appologize if I missed any review comments.
> > Patches are sent on top on next-20260309 tag
> >
> > ---
> > Eugen Hristev (21):
> > kernel: Introduce meminspect
> > init/version: Annotate static information into meminspect
> > mm/percpu: Annotate static information into meminspect
> > cpu: Annotate static information into meminspect
> > genirq/irqdesc: Annotate static information into meminspect
> > timers: Annotate static information into meminspect
> > kernel/fork: Annotate static information into meminspect
> > mm/page_alloc: Annotate static information into meminspect
> > mm/show_mem: Annotate static information into meminspect
> > mm/swapfile: Annotate static information into meminspect
> > kernel/vmcore_info: Register dynamic information into meminspect
> > kernel/configs: Register dynamic information into meminspect
> > mm/init-mm: Annotate static information into meminspect
> > panic: Annotate static information into meminspect
> > kallsyms: Annotate static information into meminspect
> > mm/mm_init: Annotate static information into meminspect
> > sched/core: Annotate runqueues into meminspect
> > remoteproc: qcom: Move minidump data structures into its own header
> > soc: qcom: Add minidump backend driver
> > soc: qcom: smem: Add minidump platform device
> > meminspect: Add debug kinfo compatible driver
> >
> > Mukesh Ojha (4):
> > mm/numa: Register node data information into meminspect
> > mm/sparse: Register information into meminspect
> > printk: Register information into meminspect
> > dt-bindings: reserved-memory: Add Google Kinfo Pixel reserved memory
> >
> > Documentation/dev-tools/index.rst | 1 +
> > Documentation/dev-tools/meminspect.rst | 144 +++++++
> > .../bindings/reserved-memory/google,kinfo.yaml | 46 ++
> > MAINTAINERS | 14 +
> > drivers/of/platform.c | 1 +
> > drivers/remoteproc/qcom_common.c | 56 +--
> > drivers/soc/qcom/Kconfig | 13 +
> > drivers/soc/qcom/Makefile | 1 +
> > drivers/soc/qcom/minidump.c | 272 ++++++++++++
> > drivers/soc/qcom/smem.c | 10 +
> > include/asm-generic/vmlinux.lds.h | 13 +
> > include/linux/meminspect.h | 263 ++++++++++++
> > include/linux/soc/qcom/minidump.h | 72 ++++
> > init/Kconfig | 1 +
> > init/version-timestamp.c | 3 +
> > init/version.c | 3 +
> > kernel/Makefile | 1 +
> > kernel/configs.c | 6 +
> > kernel/cpu.c | 5 +
> > kernel/fork.c | 3 +
> > kernel/irq/irqdesc.c | 2 +
> > kernel/kallsyms.c | 9 +
> > kernel/meminspect/Kconfig | 30 ++
> > kernel/meminspect/Makefile | 4 +
> > kernel/meminspect/kinfo.c | 284 +++++++++++++
> > kernel/meminspect/meminspect.c | 471 +++++++++++++++++++++
> > kernel/panic.c | 4 +
> > kernel/printk/printk.c | 11 +
> > kernel/sched/core.c | 2 +
> > kernel/time/timer.c | 2 +
> > kernel/vmcore_info.c | 4 +
> > mm/init-mm.c | 11 +
> > mm/mm_init.c | 2 +
> > mm/numa.c | 2 +
> > mm/page_alloc.c | 2 +
> > mm/percpu.c | 2 +
> > mm/show_mem.c | 2 +
> > mm/sparse.c | 6 +
> > mm/swapfile.c | 2 +
> > 39 files changed, 1725 insertions(+), 55 deletions(-)
> > ---
> > base-commit: 343f51842f4ed7143872f3aa116a214a5619a4b9
> > change-id: 20260311-minidump-v2-eed8da647ce5
> >
> > Best regards,
> > --
> > -Mukesh Ojha
> >
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH 0/9] Kernel API Specification Framework
From: Jakub Kicinski @ 2026-03-16 22:57 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzkaller, Sasha Levin, linux-api, linux-kernel, linux-doc,
linux-fsdevel, linux-kbuild, linux-kselftest, workflows, tools,
x86, Thomas Gleixner, Paul E. McKenney, Greg Kroah-Hartman,
Jonathan Corbet, Randy Dunlap, Cyril Hrubis, Kees Cook, Jake Edge,
David Laight, Askar Safin, Gabriele Paoloni,
Mauro Carvalho Chehab, Christian Brauner, Alexander Viro,
Andrew Morton, Masahiro Yamada, Shuah Khan, Ingo Molnar,
Arnd Bergmann
In-Reply-To: <CACT4Y+arWePyxnV3hWk5RanWZpoc7=ALQ6DV_2MCuQkNoTtJUw@mail.gmail.com>
On Mon, 16 Mar 2026 08:05:53 +0100 Dmitry Vyukov wrote:
> On Sat, 14 Mar 2026 at 19:18, Jakub Kicinski <kuba@kernel.org> wrote:
> > On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
> > > This enables static analysis tools to verify userspace API usage at compile
> > > time, test generation based on formal specifications, consistent error handling
> > > validation, automated documentation generation, and formal verification of
> > > kernel interfaces.
> >
> > Could you give some examples? We have machine readable descriptions for
> > Netlink interfaces, we approached syzbot folks and they did not really
> > seem to care for those.
>
> I think our reasoning wrt syzkaller was that not all interfaces in all
> relevant kernels are described with netlink yml descriptions, so we
> need to continue using the extraction of interfaces from the source
> code. And if we have that code, then using yml as an additional data
> source only adds code/complexity. Additionally, we may extract some
> extra constraints/info from code that are not present in yml.
>
> Realistically system call descriptions may have the same problem for
> us at this point, since we extract lots of info from the source code
> already:
> https://raw.githubusercontent.com/google/syzkaller/refs/heads/master/sys/linux/auto.txt
yup! we haven't tried to make the yml spec super useful to syzbot
to be fair. I'm just flagging that example because in our case we
quickly went from "this will obviously be useful to syzbot" to
"although we could, it may not be super practical"
> (and LLMs obviously can allow us to extract more)
Didn't even think of that. LLMs should make short work of this sort of
extraction of information from source code..
^ permalink raw reply
* Re: [PATCH 0/9] Kernel API Specification Framework
From: Sasha Levin @ 2026-03-16 23:29 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Dmitry Vyukov, syzkaller, linux-api, linux-kernel, linux-doc,
linux-fsdevel, linux-kbuild, linux-kselftest, workflows, tools,
x86, Thomas Gleixner, Paul E. McKenney, Greg Kroah-Hartman,
Jonathan Corbet, Randy Dunlap, Cyril Hrubis, Kees Cook, Jake Edge,
David Laight, Askar Safin, Gabriele Paoloni,
Mauro Carvalho Chehab, Christian Brauner, Alexander Viro,
Andrew Morton, Masahiro Yamada, Shuah Khan, Ingo Molnar,
Arnd Bergmann
In-Reply-To: <20260316155756.25b985f5@kernel.org>
On Mon, Mar 16, 2026 at 03:57:56PM -0700, Jakub Kicinski wrote:
>Didn't even think of that. LLMs should make short work of this sort of
>extraction of information from source code..
This is the primary reason that this proposal resurfaced :)
I've originally proposed[1] something like this almost a decade ago, but when I
started trying to write the actual specs I hit a brick wall: it was simply not
tractable.
With LLMs, writing the specs is something we can actually pull off, and we can
verify their correctness so LLMs don't get to hallucinate.
The specs you see in the following patches are all LLM generated.
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH v6 0/5] kunit: Add support for suppressing warning backtraces
From: Albert Esteve @ 2026-03-17 9:24 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
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Alessandro Carminati, Guenter Roeck,
Kees Cook, Albert Esteve, Linux Kernel Functional Testing,
Dan Carpenter, Maíra Canal, Kees Cook, Simona Vetter,
David Gow
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 identify and suppress specific
warning backtraces while executing test code. Support suppressing multiple
backtraces while at the same time limiting changes to generic code to the
absolute minimum.
Overview:
Patch#1 Introduces the suppression infrastructure.
Patch#2 Mitigate the impact at WARN*() sites.
Patch#3 Adds selftests to validate the functionality.
Patch#4 Demonstrates real-world usage in the DRM subsystem.
Patch#5 Documents the new API and usage guidelines.
Design Notes:
The objective is to suppress unwanted WARN*() generated messages.
Although most major architectures share common bug handling via `lib/bug.c`
and `report_bug()`, some minor or legacy architectures still rely on their
own platform-specific handling. This divergence must be considered in any
such feature. Additionally, a key challenge in implementing this feature is
the fragmentation of `WARN*()` messages emission: specific part in the
macro, common with BUG*() part in the exception handler.
As a result, any intervention to suppress the message must occur before the
illegal instruction.
Lessons from the Previous Attempt
In earlier iterations, suppression logic was added inside the
`__report_bug()` function to intercept WARN*() messages not producing
messages in the macro.
To implement the check in the bug handler code, two strategies were
considered:
* Strategy #1: Use `kallsyms` to infer the originating functionid, namely
a pointer to the function. Since in any case, the user interface relies
on function names, they must be translated in addresses at suppression-
time or at check-time.
Assuming to translate at suppression-time, the `kallsyms` subsystem needs
to be used to determine the symbol address from the name, and again to
produce the functionid from `bugaddr`. This approach proved unreliable
due to compiler-induced transformations such as inlining, cloning, and
code fragmentation. Attempts to preventing them is also unconvenient
because several `WARN()` sites are in functions intentionally declared
as `__always_inline`.
* Strategy #2: Store function name `__func__` in `struct bug_entry` in
the `__bug_table`. This implementation was used in the previous version.
However, `__func__` is a compiler-generated symbol, which complicates
relocation and linking in position-independent code. Workarounds such as
storing offsets from `.rodata` or embedding string literals directly into
the table would have significantly either increased complexity or
increase the __bug_table size.
Additionally, architectures not using the unified `BUG()` path would
still require ad-hoc handling. Because current WARN*() message production
strategy, a few WARN*() macros still need a check to suppress the part of
the message produced in the macro itself.
As a result, previous version proposed a per-macro solution, which offers
better control on where the suppression logic is applied.
For this iteration, the `__report_bug()` centralized approach was
revisited after the discussion in the previous version [1].
However, again this approach did not work because:
- Some warning output is generated directly in the macros before calling
the centralized functions (e.g., `__warn_printk()` in `__WARN_printf()`)
- Functions in the warning path like `warn_slowpath_fmt()` are marked
`__always_inline`, making it difficult to intercept early enough
- So, by the time `__report_bug()` is called, output has already been written
to the console, making suppression ineffective
Current Proposal: Check Directly in the `WARN()` Macros.
This avoids the need for function symbol resolution or ELF section
modification.
Suppression is implemented directly in the `WARN*()` macros.
A helper function, `__kunit_is_suppressed_warning()`, is used to determine
whether suppression applies. It is marked as `noinstr`, since some `WARN*()`
sites reside in non-instrumentable sections. The function uses a static
branch for the fast path check (which is `noinstr`-safe), and only calls
the actual suppression check (which uses `strcmp`, and is surrounded by
instrumentation_begin()/end() calls) when suppressions are active.
The list of suppressed warnings is protected with RCU (Read-Copy-Update)
to allow concurrent read access without locks.
To minimize runtime impact when no suppressions are active, static branching
is used via a static key (`kunit_suppress_warnings_key`). The branch is
automatically enabled when the first suppression starts and disabled when the
last suppression ends, tracked via an atomic counter. This keeps the suppression
check code out-of-line, reducing code bloat at each `WARN*()` site while
maintaining minimal runtime overhead in the common case (no active suppressions).
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.
[1] https://lore.kernel.org/all/CAGegRW76X8Fk_5qqOBw_aqBwAkQTsc8kXKHEuu9ECeXzdJwMSw@mail.gmail.com/
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.
Alessandro Carminati (2):
bug/kunit: Core support for suppressing warning backtraces
bug/kunit: Suppressing warning backtraces reduced impact on WARN*()
sites
Guenter Roeck (3):
Add unit tests to verify that warning backtrace suppression works.
drm: Suppress intentional warning backtraces in scaling unit tests
kunit: Add documentation for warning backtrace suppression API
Documentation/dev-tools/kunit/usage.rst | 30 ++++++-
drivers/gpu/drm/tests/drm_rect_test.c | 16 ++++
include/asm-generic/bug.h | 48 +++++++----
include/kunit/bug.h | 62 ++++++++++++++
include/kunit/test.h | 1 +
lib/kunit/Kconfig | 9 ++
lib/kunit/Makefile | 9 +-
lib/kunit/backtrace-suppression-test.c | 105 ++++++++++++++++++++++++
lib/kunit/bug.c | 54 ++++++++++++
9 files changed, 316 insertions(+), 18 deletions(-)
create mode 100644 include/kunit/bug.h
create mode 100644 lib/kunit/backtrace-suppression-test.c
create mode 100644 lib/kunit/bug.c
--
2.34.1
---
Alessandro Carminati (2):
bug/kunit: Core support for suppressing warning backtraces
bug/kunit: Suppressing warning backtraces reduced impact on WARN*() sites
Guenter Roeck (3):
Add unit tests to verify that warning backtrace suppression works.
drm: Suppress intentional warning backtraces in scaling unit tests
kunit: Add documentation for warning backtrace suppression API
Documentation/dev-tools/kunit/usage.rst | 30 ++++++++-
drivers/gpu/drm/tests/drm_rect_test.c | 16 +++++
include/asm-generic/bug.h | 44 ++++++++-----
include/kunit/bug.h | 61 ++++++++++++++++++
include/kunit/test.h | 1 +
lib/kunit/Kconfig | 9 +++
lib/kunit/Makefile | 9 ++-
lib/kunit/backtrace-suppression-test.c | 109 ++++++++++++++++++++++++++++++++
lib/kunit/bug.c | 71 +++++++++++++++++++++
9 files changed, 332 insertions(+), 18 deletions(-)
---
base-commit: 80234b5ab240f52fa45d201e899e207b9265ef91
change-id: 20260312-kunit_add_support-2f35806b19dd
Best regards,
--
Albert Esteve <aesteve@redhat.com>
^ permalink raw reply
* [PATCH v6 1/5] bug/kunit: Core support for suppressing warning backtraces
From: Albert Esteve @ 2026-03-17 9:24 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
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Alessandro Carminati, Guenter Roeck,
Kees Cook, Albert Esteve
In-Reply-To: <20260317-kunit_add_support-v6-0-dd22aeb3fe5d@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 identify and suppress specific
warning backtraces while executing test code. Support suppressing multiple
backtraces while at the same time limiting changes to generic code to the
absolute minimum.
Implementation details:
Check suppression directly in the `WARN()` Macros.
This avoids the need for function symbol resolution or ELF section
modification.
Use unlikely() with KUNIT_IS_SUPPRESSED_WARNING() in the Macros
so the common case (no suppression) stays on the hot path,
improving performance and keeping the critical path smaller.
A helper function, `__kunit_is_suppressed_warning()`, is used to determine
whether suppression applies. It is marked as `noinstr`, since some
`WARN*()` sites reside in non-instrumentable sections. As it uses `strcmp`,
which is not `noinstr`-safe, its use is wrapped within
`__kunit_check_suppress()` and surounded by instrumentation_begin()/end()
calls.
The list of supressed warnings includes RCU protection.
The implementation is deliberately simple and avoids architecture-specific
optimizations to preserve portability.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
include/asm-generic/bug.h | 44 ++++++++++++++++++++++------------
include/kunit/bug.h | 61 +++++++++++++++++++++++++++++++++++++++++++++++
include/kunit/test.h | 1 +
lib/kunit/Kconfig | 9 +++++++
lib/kunit/Makefile | 6 +++--
lib/kunit/bug.c | 59 +++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 163 insertions(+), 17 deletions(-)
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 09e8eccee8ed9..7c766fde49a90 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -27,6 +27,7 @@
#endif /* WARN_CONDITION_STR */
#ifndef __ASSEMBLY__
+#include <kunit/bug.h>
#include <linux/panic.h>
#include <linux/printk.h>
@@ -71,9 +72,13 @@ struct bug_entry {
*/
#ifndef HAVE_ARCH_BUG
#define BUG() do { \
- printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
- barrier_before_unreachable(); \
- panic("BUG!"); \
+ if (!unlikely(KUNIT_IS_SUPPRESSED_WARNING(__func__))) { \
+ printk("BUG: failure at %s:%d/%s()!\n", __FILE__, \
+ __LINE__, __func__); \
+ barrier_before_unreachable(); \
+ panic("BUG!"); \
+ } \
+ __builtin_unreachable(); \
} while (0)
#endif
@@ -129,18 +134,23 @@ extern __printf(1, 2) void __warn_printk(const char *fmt, ...);
#if defined(__WARN_FLAGS) && !defined(__WARN_printf)
#define __WARN_printf(taint, arg...) do { \
- instrumentation_begin(); \
- __warn_printk(arg); \
- __WARN_FLAGS("", BUGFLAG_NO_CUT_HERE | BUGFLAG_TAINT(taint));\
- instrumentation_end(); \
+ if (!unlikely(KUNIT_IS_SUPPRESSED_WARNING(__func__))) { \
+ instrumentation_begin(); \
+ __warn_printk(arg); \
+ __WARN_FLAGS("", BUGFLAG_NO_CUT_HERE | \
+ BUGFLAG_TAINT(taint)); \
+ instrumentation_end(); \
+ } \
} while (0)
#endif
#ifndef __WARN_printf
-#define __WARN_printf(taint, arg...) do { \
- instrumentation_begin(); \
- warn_slowpath_fmt(__FILE__, __LINE__, taint, arg); \
- instrumentation_end(); \
+#define __WARN_printf(taint, arg...) do { \
+ if (!unlikely(KUNIT_IS_SUPPRESSED_WARNING(__func__))) { \
+ instrumentation_begin(); \
+ warn_slowpath_fmt(__FILE__, __LINE__, taint, arg); \
+ instrumentation_end(); \
+ } \
} while (0)
#endif
@@ -153,7 +163,8 @@ extern __printf(1, 2) void __warn_printk(const char *fmt, ...);
#ifndef WARN_ON
#define WARN_ON(condition) ({ \
int __ret_warn_on = !!(condition); \
- if (unlikely(__ret_warn_on)) \
+ if (unlikely(__ret_warn_on) && \
+ !unlikely(KUNIT_IS_SUPPRESSED_WARNING(__func__))) \
__WARN(); \
unlikely(__ret_warn_on); \
})
@@ -170,7 +181,8 @@ extern __printf(1, 2) void __warn_printk(const char *fmt, ...);
#define WARN_TAINT(condition, taint, format...) ({ \
int __ret_warn_on = !!(condition); \
- if (unlikely(__ret_warn_on)) \
+ if (unlikely(__ret_warn_on) && \
+ !unlikely(KUNIT_IS_SUPPRESSED_WARNING(__func__))) \
__WARN_printf(taint, format); \
unlikely(__ret_warn_on); \
})
@@ -191,8 +203,10 @@ extern __printf(1, 2) void __warn_printk(const char *fmt, ...);
#else /* !CONFIG_BUG */
#ifndef HAVE_ARCH_BUG
#define BUG() do { \
- do {} while (1); \
- unreachable(); \
+ if (!unlikely(KUNIT_IS_SUPPRESSED_WARNING(__func__))) { \
+ do {} while (1); \
+ } \
+ unreachable(); \
} while (0)
#endif
diff --git a/include/kunit/bug.h b/include/kunit/bug.h
new file mode 100644
index 0000000000000..9a5cd226c2139
--- /dev/null
+++ b/include/kunit/bug.h
@@ -0,0 +1,61 @@
+/* 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>
+ */
+
+#ifndef _KUNIT_BUG_H
+#define _KUNIT_BUG_H
+
+#ifndef __ASSEMBLY__
+
+#include <linux/kconfig.h>
+
+#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
+
+#include <linux/stringify.h>
+#include <linux/types.h>
+
+struct __suppressed_warning {
+ struct list_head node;
+ const char *function;
+ int counter;
+};
+
+void __kunit_start_suppress_warning(struct __suppressed_warning *warning);
+void __kunit_end_suppress_warning(struct __suppressed_warning *warning);
+bool __kunit_is_suppressed_warning(const char *function);
+
+#define KUNIT_DEFINE_SUPPRESSED_WARNING(func) \
+ struct __suppressed_warning __kunit_suppress_##func = \
+ { .function = __stringify(func), .counter = 0 }
+
+#define KUNIT_START_SUPPRESSED_WARNING(func) \
+ __kunit_start_suppress_warning(&__kunit_suppress_##func)
+
+#define KUNIT_END_SUPPRESSED_WARNING(func) \
+ __kunit_end_suppress_warning(&__kunit_suppress_##func)
+
+#define KUNIT_IS_SUPPRESSED_WARNING(func) \
+ __kunit_is_suppressed_warning(func)
+
+#define KUNIT_SUPPRESSED_WARNING_COUNT(func) \
+ (__kunit_suppress_##func.counter)
+
+#define KUNIT_SUPPRESSED_WARNING_COUNT_RESET(func) \
+ __kunit_suppress_##func.counter = 0
+
+#else /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
+
+#define KUNIT_DEFINE_SUPPRESSED_WARNING(func)
+#define KUNIT_START_SUPPRESSED_WARNING(func)
+#define KUNIT_END_SUPPRESSED_WARNING(func)
+#define KUNIT_IS_SUPPRESSED_WARNING(func) ((void)(func), false)
+#define KUNIT_SUPPRESSED_WARNING_COUNT(func) ((void)(func), 0)
+#define KUNIT_SUPPRESSED_WARNING_COUNT_RESET(func)
+
+#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
+#endif /* __ASSEMBLY__ */
+#endif /* _KUNIT_BUG_H */
diff --git a/include/kunit/test.h b/include/kunit/test.h
index 9cd1594ab697d..4ec07b3fa0204 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -10,6 +10,7 @@
#define _KUNIT_TEST_H
#include <kunit/assert.h>
+#include <kunit/bug.h>
#include <kunit/try-catch.h>
#include <linux/args.h>
diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
index 498cc51e493dc..57527418fcf09 100644
--- a/lib/kunit/Kconfig
+++ b/lib/kunit/Kconfig
@@ -15,6 +15,15 @@ menuconfig KUNIT
if KUNIT
+config KUNIT_SUPPRESS_BACKTRACE
+ bool "KUnit - Enable backtrace suppression"
+ default y
+ help
+ Enable backtrace suppression for KUnit. If enabled, backtraces
+ generated intentionally by KUnit tests are suppressed. Disable
+ to reduce kernel image size if image size is more important than
+ suppression of backtraces generated by KUnit tests.
+
config KUNIT_DEBUGFS
bool "KUnit - Enable /sys/kernel/debug/kunit debugfs representation" if !KUNIT_ALL_TESTS
default KUNIT_ALL_TESTS
diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
index 656f1fa35abcc..fe177ff3ebdef 100644
--- a/lib/kunit/Makefile
+++ b/lib/kunit/Makefile
@@ -16,8 +16,10 @@ ifeq ($(CONFIG_KUNIT_DEBUGFS),y)
kunit-objs += debugfs.o
endif
-# KUnit 'hooks' are built-in even when KUnit is built as a module.
-obj-$(if $(CONFIG_KUNIT),y) += hooks.o
+# KUnit 'hooks' and bug handling are built-in even when KUnit is built
+# as a module.
+obj-$(if $(CONFIG_KUNIT),y) += hooks.o \
+ bug.o
obj-$(CONFIG_KUNIT_TEST) += kunit-test.o
obj-$(CONFIG_KUNIT_TEST) += platform-test.o
diff --git a/lib/kunit/bug.c b/lib/kunit/bug.c
new file mode 100644
index 0000000000000..53c98e225a895
--- /dev/null
+++ b/lib/kunit/bug.c
@@ -0,0 +1,59 @@
+// 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/bug.h>
+#include <linux/export.h>
+#include <linux/instrumentation.h>
+#include <linux/rculist.h>
+#include <linux/string.h>
+
+#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
+
+static LIST_HEAD(suppressed_warnings);
+
+void __kunit_start_suppress_warning(struct __suppressed_warning *warning)
+{
+ list_add_rcu(&warning->node, &suppressed_warnings);
+}
+EXPORT_SYMBOL_GPL(__kunit_start_suppress_warning);
+
+void __kunit_end_suppress_warning(struct __suppressed_warning *warning)
+{
+ list_del_rcu(&warning->node);
+ synchronize_rcu(); /* Wait for readers to finish */
+}
+EXPORT_SYMBOL_GPL(__kunit_end_suppress_warning);
+
+static bool __kunit_check_suppress(const char *function)
+{
+ struct __suppressed_warning *warning;
+
+ if (!function)
+ return false;
+
+ list_for_each_entry(warning, &suppressed_warnings, node) {
+ if (!strcmp(function, warning->function)) {
+ warning->counter++;
+ return true;
+ }
+ }
+ return false;
+}
+
+noinstr bool __kunit_is_suppressed_warning(const char *function)
+{
+ bool ret;
+
+ instrumentation_begin();
+ ret = __kunit_check_suppress(function);
+ instrumentation_end();
+ return ret;
+}
+EXPORT_SYMBOL_GPL(__kunit_is_suppressed_warning);
+
+#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
--
2.52.0
^ permalink raw reply related
* [PATCH v6 2/5] bug/kunit: Suppressing warning backtraces reduced impact on WARN*() sites
From: Albert Esteve @ 2026-03-17 9:24 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
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Alessandro Carminati, Albert Esteve
In-Reply-To: <20260317-kunit_add_support-v6-0-dd22aeb3fe5d@redhat.com>
From: Alessandro Carminati <acarmina@redhat.com>
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 uses static branching to minimize code size
and runtime overhead when no suppressions are active. In that case,
the static branch compiles to a single no-op instruction (5 bytes on
x86), avoiding any memory loads or branch prediction overhead. The
branch is automatically enabled when the first suppression starts and
disabled when the last suppression ends.
Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
lib/kunit/bug.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/lib/kunit/bug.c b/lib/kunit/bug.c
index 53c98e225a895..9c2c4ee013d92 100644
--- a/lib/kunit/bug.c
+++ b/lib/kunit/bug.c
@@ -7,17 +7,25 @@
*/
#include <kunit/bug.h>
+#include <linux/atomic.h>
#include <linux/export.h>
#include <linux/instrumentation.h>
+#include <linux/jump_label.h>
#include <linux/rculist.h>
#include <linux/string.h>
#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
static LIST_HEAD(suppressed_warnings);
+static atomic_t suppressed_symbols_cnt = ATOMIC_INIT(0);
+
+DEFINE_STATIC_KEY_FALSE(kunit_suppress_warnings_key);
+EXPORT_SYMBOL_GPL(kunit_suppress_warnings_key);
void __kunit_start_suppress_warning(struct __suppressed_warning *warning)
{
+ if (atomic_inc_return(&suppressed_symbols_cnt) == 1)
+ static_branch_enable(&kunit_suppress_warnings_key);
list_add_rcu(&warning->node, &suppressed_warnings);
}
EXPORT_SYMBOL_GPL(__kunit_start_suppress_warning);
@@ -26,6 +34,8 @@ void __kunit_end_suppress_warning(struct __suppressed_warning *warning)
{
list_del_rcu(&warning->node);
synchronize_rcu(); /* Wait for readers to finish */
+ if (atomic_dec_return(&suppressed_symbols_cnt) == 0)
+ static_branch_disable(&kunit_suppress_warnings_key);
}
EXPORT_SYMBOL_GPL(__kunit_end_suppress_warning);
@@ -49,6 +59,8 @@ noinstr bool __kunit_is_suppressed_warning(const char *function)
{
bool ret;
+ if (!static_branch_unlikely(&kunit_suppress_warnings_key))
+ return false;
instrumentation_begin();
ret = __kunit_check_suppress(function);
instrumentation_end();
--
2.52.0
^ permalink raw reply related
* [PATCH v6 3/5] Add unit tests to verify that warning backtrace suppression works.
From: Albert Esteve @ 2026-03-17 9:24 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
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter,
Alessandro Carminati, Albert Esteve, Kees Cook
In-Reply-To: <20260317-kunit_add_support-v6-0-dd22aeb3fe5d@redhat.com>
From: Guenter Roeck <linux@roeck-us.net>
Add unit tests to verify that warning backtrace suppression works.
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>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
lib/kunit/Makefile | 3 +
lib/kunit/backtrace-suppression-test.c | 109 +++++++++++++++++++++++++++++++++
2 files changed, 112 insertions(+)
diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
index fe177ff3ebdef..b2f2b8ada7b71 100644
--- a/lib/kunit/Makefile
+++ b/lib/kunit/Makefile
@@ -23,6 +23,9 @@ obj-$(if $(CONFIG_KUNIT),y) += hooks.o \
obj-$(CONFIG_KUNIT_TEST) += kunit-test.o
obj-$(CONFIG_KUNIT_TEST) += platform-test.o
+ifeq ($(CONFIG_KUNIT_SUPPRESS_BACKTRACE),y)
+obj-$(CONFIG_KUNIT_TEST) += backtrace-suppression-test.o
+endif
# 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..524aecee0ee23
--- /dev/null
+++ b/lib/kunit/backtrace-suppression-test.c
@@ -0,0 +1,109 @@
+// 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>
+
+static void backtrace_suppression_test_warn_direct(struct kunit *test)
+{
+ KUNIT_DEFINE_SUPPRESSED_WARNING(backtrace_suppression_test_warn_direct);
+
+ KUNIT_START_SUPPRESSED_WARNING(backtrace_suppression_test_warn_direct);
+ WARN(1, "This backtrace should be suppressed");
+ KUNIT_END_SUPPRESSED_WARNING(backtrace_suppression_test_warn_direct);
+
+ KUNIT_EXPECT_EQ(test,
+ KUNIT_SUPPRESSED_WARNING_COUNT(backtrace_suppression_test_warn_direct), 1);
+}
+
+static void trigger_backtrace_warn(void)
+{
+ WARN(1, "This backtrace should be suppressed");
+}
+
+static void backtrace_suppression_test_warn_indirect(struct kunit *test)
+{
+ KUNIT_DEFINE_SUPPRESSED_WARNING(trigger_backtrace_warn);
+
+ KUNIT_START_SUPPRESSED_WARNING(trigger_backtrace_warn);
+ trigger_backtrace_warn();
+ KUNIT_END_SUPPRESSED_WARNING(trigger_backtrace_warn);
+
+ KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(trigger_backtrace_warn), 1);
+}
+
+static void backtrace_suppression_test_warn_multi(struct kunit *test)
+{
+ KUNIT_DEFINE_SUPPRESSED_WARNING(trigger_backtrace_warn);
+ KUNIT_DEFINE_SUPPRESSED_WARNING(backtrace_suppression_test_warn_multi);
+
+ KUNIT_START_SUPPRESSED_WARNING(backtrace_suppression_test_warn_multi);
+ KUNIT_START_SUPPRESSED_WARNING(trigger_backtrace_warn);
+ WARN(1, "This backtrace should be suppressed");
+ trigger_backtrace_warn();
+ KUNIT_END_SUPPRESSED_WARNING(trigger_backtrace_warn);
+ KUNIT_END_SUPPRESSED_WARNING(backtrace_suppression_test_warn_multi);
+
+ KUNIT_EXPECT_EQ(test,
+ KUNIT_SUPPRESSED_WARNING_COUNT(backtrace_suppression_test_warn_multi), 1);
+ KUNIT_EXPECT_EQ(test,
+ KUNIT_SUPPRESSED_WARNING_COUNT(trigger_backtrace_warn), 1);
+}
+
+static void backtrace_suppression_test_warn_on_direct(struct kunit *test)
+{
+ KUNIT_DEFINE_SUPPRESSED_WARNING(backtrace_suppression_test_warn_on_direct);
+
+ if (!IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE) && !IS_ENABLED(CONFIG_KALLSYMS))
+ kunit_skip(test, "requires CONFIG_DEBUG_BUGVERBOSE or CONFIG_KALLSYMS");
+
+ KUNIT_START_SUPPRESSED_WARNING(backtrace_suppression_test_warn_on_direct);
+ WARN_ON(1);
+ KUNIT_END_SUPPRESSED_WARNING(backtrace_suppression_test_warn_on_direct);
+
+ KUNIT_EXPECT_EQ(test,
+ KUNIT_SUPPRESSED_WARNING_COUNT(
+ backtrace_suppression_test_warn_on_direct), 1);
+}
+
+static void trigger_backtrace_warn_on(void)
+{
+ WARN_ON(1);
+}
+
+static void backtrace_suppression_test_warn_on_indirect(struct kunit *test)
+{
+ KUNIT_DEFINE_SUPPRESSED_WARNING(trigger_backtrace_warn_on);
+
+ if (!IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE))
+ kunit_skip(test, "requires CONFIG_DEBUG_BUGVERBOSE");
+
+ KUNIT_START_SUPPRESSED_WARNING(trigger_backtrace_warn_on);
+ trigger_backtrace_warn_on();
+ KUNIT_END_SUPPRESSED_WARNING(trigger_backtrace_warn_on);
+
+ KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(trigger_backtrace_warn_on), 1);
+}
+
+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),
+ {}
+};
+
+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.52.0
^ permalink raw reply related
* [PATCH v6 4/5] drm: Suppress intentional warning backtraces in scaling unit tests
From: Albert Esteve @ 2026-03-17 9:24 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
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter, Maíra Canal,
Alessandro Carminati, Albert Esteve, Simona Vetter
In-Reply-To: <20260317-kunit_add_support-v6-0-dd22aeb3fe5d@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.
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>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
drivers/gpu/drm/tests/drm_rect_test.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_rect_test.c b/drivers/gpu/drm/tests/drm_rect_test.c
index 17e1f34b76101..867845e7d5ab6 100644
--- a/drivers/gpu/drm/tests/drm_rect_test.c
+++ b/drivers/gpu/drm/tests/drm_rect_test.c
@@ -406,22 +406,38 @@ 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)
{
+ KUNIT_DEFINE_SUPPRESSED_WARNING(drm_calc_scale);
const struct drm_rect_scale_case *params = test->param_value;
int scaling_factor;
+ /*
+ * drm_rect_calc_hscale() generates a warning backtrace whenever bad
+ * parameters are passed to it. This affects all unit tests with an
+ * error code in expected_scaling_factor.
+ */
+ KUNIT_START_SUPPRESSED_WARNING(drm_calc_scale);
scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
params->min_range, params->max_range);
+ KUNIT_END_SUPPRESSED_WARNING(drm_calc_scale);
KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
}
static void drm_test_rect_calc_vscale(struct kunit *test)
{
+ KUNIT_DEFINE_SUPPRESSED_WARNING(drm_calc_scale);
const struct drm_rect_scale_case *params = test->param_value;
int scaling_factor;
+ /*
+ * drm_rect_calc_vscale() generates a warning backtrace whenever bad
+ * parameters are passed to it. This affects all unit tests with an
+ * error code in expected_scaling_factor.
+ */
+ KUNIT_START_SUPPRESSED_WARNING(drm_calc_scale);
scaling_factor = drm_rect_calc_vscale(¶ms->src, ¶ms->dst,
params->min_range, params->max_range);
+ KUNIT_END_SUPPRESSED_WARNING(drm_calc_scale);
KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
}
--
2.52.0
^ permalink raw reply related
* [PATCH v6 5/5] kunit: Add documentation for warning backtrace suppression API
From: Albert Esteve @ 2026-03-17 9:24 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
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter,
Alessandro Carminati, Albert Esteve, Kees Cook, David Gow
In-Reply-To: <20260317-kunit_add_support-v6-0-dd22aeb3fe5d@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>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
Documentation/dev-tools/kunit/usage.rst | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index ebd06f5ea4550..f1f8e2619d2d6 100644
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@@ -157,6 +157,34 @@ 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 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.
+
+Such backtraces can be suppressed. To suppress a backtrace in some_function(),
+use the following code.
+
+.. code-block:: c
+
+ static void some_test(struct kunit *test)
+ {
+ DEFINE_SUPPRESSED_WARNING(some_function);
+
+ KUNIT_START_SUPPRESSED_WARNING(some_function);
+ trigger_backtrace();
+ KUNIT_END_SUPPRESSED_WARNING(some_function);
+ }
+
+SUPPRESSED_WARNING_COUNT() returns the number of suppressed backtraces. If the
+suppressed backtrace was triggered on purpose, this can be used to check if
+the backtrace was actually triggered.
+
+.. code-block:: c
+
+ KUNIT_EXPECT_EQ(test, SUPPRESSED_WARNING_COUNT(some_function), 1);
Test Suites
~~~~~~~~~~~
@@ -1211,4 +1239,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.52.0
^ permalink raw reply related
* Re: [PATCH v6 0/5] kunit: Add support for suppressing warning backtraces
From: Dan Carpenter @ 2026-03-17 10:03 UTC (permalink / raw)
To: Albert Esteve
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, linux-kernel,
linux-arch, linux-kselftest, kunit-dev, dri-devel, workflows,
linux-doc, Alessandro Carminati, Guenter Roeck, Kees Cook,
Linux Kernel Functional Testing, Maíra Canal, Simona Vetter
In-Reply-To: <20260317-kunit_add_support-v6-0-dd22aeb3fe5d@redhat.com>
I think this is great to suppress some warnings, and I already ACKed
this patchset. But we're still going to have some warnings where the
warning is the whole point of the test.
It would be great if marked these somehow:
1) At minimum we should mark them so people seeing the warning know it's
intentional. "Intentional Stack Trace". I've sent at least one patch
to add that printk before the stack trace but it was ignored. We could
do this piecemeal.
2) It would be nice if the print was standardized enough so CI systems
could automatically filter it out.
regards,
dan carpenter
^ 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