* Re: [PATCH v5 06/14] module: Switch load_info::len to size_t
From: Thomas Weißschuh @ 2026-05-26 11:35 UTC (permalink / raw)
To: Petr Pavlu
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Nathan Chancellor,
Nicolas Schier, Arnd Bergmann, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Paul Moore, James Morris, Serge E. Hallyn,
Jonathan Corbet, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Naveen N Rao, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Nicolas Schier, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Martin KaFai Lau, Song Liu, Yonghong Song,
Jiri Olsa, bpf, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Eric Biggers, Sebastian Andrzej Siewior, linux-kbuild,
linux-kernel, linux-arch, linux-modules, linux-security-module,
linux-doc, linuxppc-dev, linux-integrity, debian-kernel
In-Reply-To: <8de0e6ad-987a-4729-bbd0-8399968dbb48@suse.com>
On 2026-05-26 11:47:09+0200, Petr Pavlu wrote:
> On 5/5/26 11:05 AM, Thomas Weißschuh wrote:
> > Switching the types will make some later changes cleaner.
>
> Since the updated version drops the patch "module: Deduplicate signature
> extraction", I believe this change is no longer necessary.
Ack.
(...)
Thomas
^ permalink raw reply
* Re: [PATCH v5 07/14] module: Make module authentication usable without MODULE_SIG
From: Petr Pavlu @ 2026-05-26 10:53 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Nathan Chancellor,
Nicolas Schier, Arnd Bergmann, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Paul Moore, James Morris, Serge E. Hallyn,
Jonathan Corbet, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Naveen N Rao, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Nicolas Schier, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Martin KaFai Lau, Song Liu, Yonghong Song,
Jiri Olsa, bpf, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Eric Biggers, Sebastian Andrzej Siewior, linux-kbuild,
linux-kernel, linux-arch, linux-modules, linux-security-module,
linux-doc, linuxppc-dev, linux-integrity, debian-kernel
In-Reply-To: <20260505-module-hashes-v5-7-e174a5a49fce@weissschuh.net>
On 5/5/26 11:05 AM, Thomas Weißschuh wrote:
> The module authentication functionality will also be used by the
> hash-based module authentication. Split it out from CONFIG_MODULE_SIG
> so it is usable by both.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> [...]
> diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
> index f535181e0d98..84297da666ff 100644
> --- a/kernel/module/Kconfig
> +++ b/kernel/module/Kconfig
> @@ -271,9 +271,12 @@ config MODULE_SIG
> debuginfo strip done by some packagers (such as rpmbuild) and
> inclusion into an initramfs that wants the module size reduced.
>
> +config MODULE_AUTH
> + def_bool MODULE_SIG
> +
> config MODULE_SIG_FORCE
> bool "Require modules to be validly signed"
> - depends on MODULE_SIG
> + depends on MODULE_AUTH
> help
> Reject unsigned modules or signed modules for which we don't have a
> key. Without this, such modules will simply taint the kernel.
Should MODULE_SIG_FORCE be renamed to MODULE_AUTH_FORCE, along with
renaming the sig_enforce functionality in kernel/module/auth.c to
auth_enforce?
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v5 06/14] module: Switch load_info::len to size_t
From: Petr Pavlu @ 2026-05-26 9:47 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Nathan Chancellor,
Nicolas Schier, Arnd Bergmann, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Paul Moore, James Morris, Serge E. Hallyn,
Jonathan Corbet, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Naveen N Rao, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Nicolas Schier, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Martin KaFai Lau, Song Liu, Yonghong Song,
Jiri Olsa, bpf, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Eric Biggers, Sebastian Andrzej Siewior, linux-kbuild,
linux-kernel, linux-arch, linux-modules, linux-security-module,
linux-doc, linuxppc-dev, linux-integrity, debian-kernel
In-Reply-To: <20260505-module-hashes-v5-6-e174a5a49fce@weissschuh.net>
On 5/5/26 11:05 AM, Thomas Weißschuh wrote:
> Switching the types will make some later changes cleaner.
Since the updated version drops the patch "module: Deduplicate signature
extraction", I believe this change is no longer necessary.
> size_t is also the semantically correct type for this field.
>
> As both 'size_t' and 'unsigned long' are always the same size, this
> should be risk-free.
The module 'len' would now start in init_module() as 'unsigned long',
then change in copy_module_from_user() to size_t, and then back to
'unsigned long' when calling copy_chunked_from_user(). The current code
is more consistent and mostly uses 'unsigned long', matching the syscall
interface.
--
Thanks,
Petr
^ permalink raw reply
* Re: build failure for stablerc
From: Petr Pavlu @ 2026-05-26 7:31 UTC (permalink / raw)
To: Toralf Förster; +Cc: linux-modules, linux-kbuild, Linux Kernel
In-Reply-To: <a47f9124-15b3-4dbc-a211-6161eb98406c@gmx.de>
On 5/25/26 9:39 PM, Toralf Förster wrote:
> Hi,
>
> at a small Hetzner VPS at x86 the compilation of the stablerc v7.0.5-1656-ge79d5c5d57c0 fails under Ubuntu-26.04 with
>
> WRAP arch/x86/include/generated/asm/mmiowb.h
> WRAP arch/x86/include/generated/asm/module.lds.h
> WRAP arch/x86/include/generated/asm/rwonce.h
> UPD include/generated/utsrelease.h
> CC /root/linux/tools/objtool/libsubcmd/run-command.o
> HOSTCC scripts/gendwarfksyms/gendwarfksyms.o
> In file included from scripts/gendwarfksyms/gendwarfksyms.c:12:
> scripts/gendwarfksyms/gendwarfksyms.h:6:10: fatal error: dwarf.h: No such file or directory
> 6 | #include <dwarf.h>
> | ^~~~~~~~~
> compilation terminated.
> make[3]: *** [scripts/Makefile.host:131: scripts/gendwarfksyms/gendwarfksyms.o] Error 1
> make[2]: *** [scripts/Makefile.build:548: scripts/gendwarfksyms] Error 2
> make[1]: *** [/root/linux/Makefile:1325: scripts] Error 2
> make[1]: *** Waiting for unfinished jobs....
> CC /root/linux/tools/objtool/libsubcmd/sigchain.o
Gendwarfksyms requires libdw, see Documentation/kbuild/gendwarfksyms.rst
[1]. Is the library and its development files installed on your system?
If you write a trivial program that includes <dwarf.h>, can the compiler
find it in the default search locations?
[1] https://github.com/torvalds/linux/blob/v7.1-rc5/Documentation/kbuild/gendwarfksyms.rst
-- Petr
^ permalink raw reply
* Re: [PATCH 00/11] Convert moduleparams to seq_buf
From: Petr Pavlu @ 2026-05-26 6:53 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521133315.work.845-kees@kernel.org>
On 5/21/26 3:33 PM, Kees Cook wrote:
> Hi,
>
> I tried to trim the CC list here, but it's still pretty huge...
>
> We've had a long-standing issue with "write to a string pointer" callbacks
> that don't bounds check the destination (and for which the bounds is
> also not part of the callback prototype, even if it is "known" to be
> PAGE_SIZE, which sysfs_emit() depends on). Both moduleparams and sysfs
> use this pattern. As a first step, and to test the migration method,
> migrate moduleparams first.
>
> There are 2 "mechanical" treewide patches that are handled by Coccinelle:
> - treewide: Convert struct kernel_param_ops initializers to DEFINE_KERNEL_PARAM_OPS
> - treewide: Convert custom kernel_param_ops .get callbacks to seq_buf via cocci
>
> The last treewide patch is manual, and may need to be broken up into
> per-subsystem patches, though I'd prefer to avoid this, as it would
> extend the migration from 1 relase to at least 2 releases. (1 to
> release the migration infrastructure, then 1 release to collect all the
> subsystem changes, and possibly 1 more release to remove the migration
> infrastructure.)
>
> Thoughts, questions?
This looks reasonable to me. I added a few minor comments on the patches
but they already look solid.
--
Thanks,
Petr
^ permalink raw reply
* build failure for stablerc
From: Toralf Förster @ 2026-05-25 19:39 UTC (permalink / raw)
To: linux-modules, linux-kbuild; +Cc: Linux Kernel
Hi,
at a small Hetzner VPS at x86 the compilation of the stablerc
v7.0.5-1656-ge79d5c5d57c0 fails under Ubuntu-26.04 with
WRAP arch/x86/include/generated/asm/mmiowb.h
WRAP arch/x86/include/generated/asm/module.lds.h
WRAP arch/x86/include/generated/asm/rwonce.h
UPD include/generated/utsrelease.h
CC /root/linux/tools/objtool/libsubcmd/run-command.o
HOSTCC scripts/gendwarfksyms/gendwarfksyms.o
In file included from scripts/gendwarfksyms/gendwarfksyms.c:12:
scripts/gendwarfksyms/gendwarfksyms.h:6:10: fatal error: dwarf.h: No
such file or directory
6 | #include <dwarf.h>
| ^~~~~~~~~
compilation terminated.
make[3]: *** [scripts/Makefile.host:131:
scripts/gendwarfksyms/gendwarfksyms.o] Error 1
make[2]: *** [scripts/Makefile.build:548: scripts/gendwarfksyms] Error 2
make[1]: *** [/root/linux/Makefile:1325: scripts] Error 2
make[1]: *** Waiting for unfinished jobs....
CC /root/linux/tools/objtool/libsubcmd/sigchain.o
The .config was derived from the Hetzner image and tweaked via [1]
[1]
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup_kernel/defaults/main.yaml#L9
--
Toralf
^ permalink raw reply
* Re: [PATCH v2] genksyms: Support arm64 CRC32 hardware acceleration1~
From: Petr Pavlu @ 2026-05-25 17:33 UTC (permalink / raw)
To: Wentao Guan; +Cc: linux-kbuild, linux-kernel, linux-modules, masahiroy
In-Reply-To: <tencent_23032AC04EF146C803D19A6D@qq.com>
On 5/25/26 3:41 PM, Wentao Guan wrote:
>> On 5/25/26 10:02 AM, Wentao Guan wrote:
>>>> Additionally, many distributions already switched to gendwarfksyms last
>>>> year. Unless someone provides a good reason to keep genksyms around,
>>>> I expect it will be deprecated soon and eventually removed. It would be
>>>> more valuable to show whether the same optimization is worthwhile for
>>>> gendwarfksyms.
>>> I see gendwarfksyms use crc32 from <zlib.h>, which from zlib1g-dev and zlib1g.
>>
>> Ah, I forgot about this, so gendwarfksyms should already be well
>> optimized. I think that is the most important thing.
>
> Which way do you prefer? There are two ways now:
> 1. this work,
> 2. import zlib like gendwarfksyms and remove the huge crctab,
> but need make sure any arch do not cause performance regression?
> (Assert the user libs precompile with +crc32 is right?)
> I do some early tests show that:
> 1) zlib in x86 fast than genksym software
> 2) zlib in arm64 debian precompile slow than genksym software(crc32 not in armv8)
> 3) zlib in arm64 recompile with +crc32 same speed with genksyms hardware
I think it would be useful to first have more data showing that the CRC
calculation in genksyms is a hot path and contributes significantly to
the overall kernel build time.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH 08/11] params: Convert generic kernel_param_ops .get helpers to seq_buf
From: Petr Pavlu @ 2026-05-25 17:10 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521133326.2465264-8-kees@kernel.org>
On 5/21/26 3:33 PM, Kees Cook wrote:
> Convert the generic struct kernel_param_ops .get helpers in
> kernel/params.c directly to the seq_buf signature, drop their legacy
> "char *" form, and refresh prototypes in <linux/moduleparam.h>:
>
> param_get_byte/short/ushort/int/uint/long/ulong/ullong/hexint
> param_get_charp/bool/invbool/string
> param_array_get
>
> The STANDARD_PARAM_DEF() macro expands to a seq_buf body for every
> numeric helper. param_array_get() now writes element output directly
> into the parent seq_buf when the element ops provide .get; it only
> allocates the per-call PAGE_SIZE bounce buffer when the element ops
> still use the legacy .get_str path. The common "rewrite the prior
> element's trailing newline as a comma" step lives outside both
> branches so the two paths share it.
>
> The non-core changes in this commit (arch/x86/kvm, mm/kfence,
> drivers/dma/dmatest, security/apparmor) are the small set of callers that
> directly invoke one of the converted generic helpers from their own .get
> callback (e.g. an apparmor wrapper that adds a capability check and then
> delegates to param_get_bool()). Because the helpers' signature changes
> here, these wrappers must move in lockstep. Each of them is updated
> to take "struct seq_buf *" and pass it through; param_get_debug() in
> apparmor also pulls aa_print_debug_params() (and its val_mask_to_str()
> helper, in security/apparmor/lib.c) over to seq_buf, since that is the
> only consumer. No other behavioural change is intended.
>
> Custom .get callbacks that do not delegate to a generic helper (and
> therefore still match the .get_str signature) are routed automatically
> to the .get_str field by the DEFINE_KERNEL_PARAM_OPS _Generic dispatcher
> and are deliberately left alone here, to be changed separately within
> their respective subsystems.
>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> [...]
> @@ -453,36 +457,46 @@ static int param_array_set(const char *val, const struct kernel_param *kp)
> arr->num ?: &temp_num);
> }
>
> -static int param_array_get(char *buffer, const struct kernel_param *kp)
> +static int param_array_get(struct seq_buf *s, const struct kernel_param *kp)
> {
> - int i, off, ret;
> - char *elem_buf;
> const struct kparam_array *arr = kp->arr;
> struct kernel_param p = *kp;
> + char *elem_buf = NULL;
> + int i, ret = 0;
>
> - elem_buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
> - if (!elem_buf)
> - return -ENOMEM;
> + for (i = 0; i < (arr->num ? *arr->num : arr->max); i++) {
> + size_t before = s->len;
>
> - for (i = off = 0; i < (arr->num ? *arr->num : arr->max); i++) {
> p.arg = arr->elem + arr->elemsize * i;
> check_kparam_locked(p.mod);
> - ret = arr->ops->get_str(elem_buf, &p);
> - if (ret < 0)
> - goto out;
> - ret = min(ret, (int)(PAGE_SIZE - 1 - off));
> - if (!ret)
> +
> + if (arr->ops->get) {
> + ret = arr->ops->get(s, &p);
> + if (ret < 0)
> + goto out;
> + } else {
> + if (!elem_buf) {
> + elem_buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!elem_buf) {
> + ret = -ENOMEM;
> + goto out;
> + }
> + }
> + ret = arr->ops->get_str(elem_buf, &p);
> + if (ret < 0)
> + goto out;
> + seq_buf_putmem(s, elem_buf, ret);
> + }
> +
> + /* Nothing got written (e.g. overflow) — stop. */
> + if (s->len == before)
> break;
> +
> /* Replace the previous element's trailing newline with a comma. */
> - if (i)
> - buffer[off - 1] = ',';
> - memcpy(buffer + off, elem_buf, ret);
> - off += ret;
> - if (off == PAGE_SIZE - 1)
> - break;
> + if (i && s->buffer[before - 1] == '\n')
> + s->buffer[before - 1] = ',';
> }
> - buffer[off] = '\0';
> - ret = off;
> + ret = 0;
> out:
> kfree(elem_buf);
> return ret;
Since you're almost completely rewriting the logic in param_array_get(),
I suggest tightening it up a bit. The function could warn or return an
error when a kernel_param_ops::get/get_str() call adds a string that
doesn't terminate with '\n', specifically, when the call adds either
a zero-length string or a non-zero-length string that ends with
a different character (unless an overflow occurred).
The updated code silently stops the loop when a get call returns
a zero-length string. Similarly, handling of a string not terminated by
'\n' is halfway there because of the added check
"s->buffer[before - 1] == '\n'".
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH 07/11] moduleparam: Route DEFINE_KERNEL_PARAM_OPS get pointer via _Generic
From: Petr Pavlu @ 2026-05-25 16:24 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521133326.2465264-7-kees@kernel.org>
On 5/21/26 3:33 PM, Kees Cook wrote:
> Make the DEFINE_KERNEL_PARAM_OPS family route their _get argument to
> either .get (struct seq_buf *) or .get_str (char *) at compile time
> based on the pointer's actual function signature. Two helper macros
> do the routing:
>
> _KERNEL_PARAM_OPS_GET - return the pointer if it has the seq_buf
> signature, otherwise NULL of that type
> _KERNEL_PARAM_OPS_GET_STR - mirror image for the char * signature
>
> Both use _Generic; only the two valid function-pointer types are
> listed, so any third-party type is a compile error rather than
> silently falling through.
>
> Now a callback whose body has been migrated from char * to struct
> seq_buf * needs no change at its kernel_param_ops initialization site,
> because the macro picks up the new type automatically and assigns to
> the correct field.
>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> include/linux/moduleparam.h | 33 ++++++++++++++++++++++++++-------
> 1 file changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index c52120f6ac28..795bc7c654ef 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -85,15 +85,32 @@ struct kernel_param_ops {
> *
> * static DEFINE_KERNEL_PARAM_OPS(my_ops, my_set, my_get);
> *
> - * Routing the @_set and @_get function pointers through the macro
> - * (rather than naming the struct fields at every call site) lets the
> - * field layout change in one place when callbacks are migrated to a
> - * new signature.
> + * @_get may be either of:
> + * int (*)(struct seq_buf *, const struct kernel_param *) (seq_buf)
> + * int (*)(char *, const struct kernel_param *) (legacy)
> + *
> + * The macro uses _Generic to route the function pointer to the
> + * matching field (.get or .get_str) at compile time, leaving the
> + * other field NULL. Each helper matches the wrong prototype signature
> + * and returns NULL, falling through to the default branch otherwise;
> + * if @_get has neither expected signature the assignment to the
> + * fields gets a normal compile-time type-mismatch error.
> */
> +#define _KERNEL_PARAM_OPS_GET(_get) \
> + _Generic((_get), \
> + int (*)(char *, const struct kernel_param *): NULL, \
> + default: (_get))
> +
> +#define _KERNEL_PARAM_OPS_GET_STR(_get) \
> + _Generic((_get), \
> + int (*)(struct seq_buf *, const struct kernel_param *): NULL, \
> + default: (_get))
> +
> #define DEFINE_KERNEL_PARAM_OPS(_name, _set, _get) \
> const struct kernel_param_ops _name = { \
> .set = (_set), \
> - .get_str = (_get), \
> + .get = _KERNEL_PARAM_OPS_GET(_get), \
> + .get_str = _KERNEL_PARAM_OPS_GET_STR(_get), \
> }
>
> /* As DEFINE_KERNEL_PARAM_OPS, with KERNEL_PARAM_OPS_FL_NOARG set. */
> @@ -101,14 +118,16 @@ struct kernel_param_ops {
> const struct kernel_param_ops _name = { \
> .flags = KERNEL_PARAM_OPS_FL_NOARG, \
> .set = (_set), \
> - .get_str = (_get), \
> + .get = _KERNEL_PARAM_OPS_GET(_get), \
> + .get_str = _KERNEL_PARAM_OPS_GET_STR(_get), \
> }
>
> /* As DEFINE_KERNEL_PARAM_OPS, with an additional .free callback. */
> #define DEFINE_KERNEL_PARAM_OPS_FREE(_name, _set, _get, _free) \
> const struct kernel_param_ops _name = { \
> .set = (_set), \
> - .get_str = (_get), \
> + .get = _KERNEL_PARAM_OPS_GET(_get), \
> + .get_str = _KERNEL_PARAM_OPS_GET_STR(_get), \
> .free = (_free), \
> }
>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
-- Petr
^ permalink raw reply
* Re: [PATCH 06/11] moduleparam: Add seq_buf-based .get callback alongside .get_str
From: Petr Pavlu @ 2026-05-25 16:19 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521133326.2465264-6-kees@kernel.org>
On 5/21/26 3:33 PM, Kees Cook wrote:
> Add a new struct kernel_param_ops::get callback whose signature
> takes a struct seq_buf instead of a raw char buffer:
>
> int (*get)(struct seq_buf *sb, const struct kernel_param *kp);
>
> The previously-legacy .get field is now .get_str (char *buffer);
> .get is the new seq_buf-aware form. param_attr_show() prefers .get
> when set, otherwise falls back to .get_str. WARN_ON_ONCE() if both
> are set. Return contract for .get:
>
> < 0 : errno propagated to userspace; seq_buf contents discarded
> = 0 : success; length derived from seq_buf_used()
> > 0 : forbidden; the dispatcher WARN_ON_ONCE()s and treats as 0
>
> The default policy on seq_buf_has_overflowed() is silent truncation,
> matching scnprintf()/sysfs_emit() behaviour. Callbacks that want a
> specific overflow errno can check seq_buf_has_overflowed() and
> return their preferred error.
>
> No callbacks use .get yet; the legacy path is still the only one in use
> after this commit. A subsequent commit teaches DEFINE_KERNEL_PARAM_OPS
> to route initializers by type.
>
> Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
-- Petr
^ permalink raw reply
* Re: [PATCH v2] genksyms: Support arm64 CRC32 hardware acceleration1~
From: Wentao Guan @ 2026-05-25 13:41 UTC (permalink / raw)
To: Petr Pavlu; +Cc: linux-kbuild, linux-kernel, linux-modules, masahiroy
In-Reply-To: <26c47a0e-7a9b-473a-818d-455e68476dd1@suse.com>
>On 5/25/26 10:02 AM, Wentao Guan wrote:
>>> Additionally, many distributions already switched to gendwarfksyms last
>>> year. Unless someone provides a good reason to keep genksyms around,
>>> I expect it will be deprecated soon and eventually removed. It would be
>>> more valuable to show whether the same optimization is worthwhile for
>>> gendwarfksyms.
>> I see gendwarfksyms use crc32 from <zlib.h>, which from zlib1g-dev and zlib1g.
>
> Ah, I forgot about this, so gendwarfksyms should already be well
> optimized. I think that is the most important thing.
Which way do you prefer? There are two ways now:
1. this work,
2. import zlib like gendwarfksyms and remove the huge crctab,
but need make sure any arch do not cause performance regression?
(Assert the user libs precompile with +crc32 is right?)
I do some early tests show that:
1) zlib in x86 fast than genksym software
2) zlib in arm64 debian precompile slow than genksym software(crc32 not in armv8)
3) zlib in arm64 recompile with +crc32 same speed with genksyms hardware
BRs
Wentao Guan
^ permalink raw reply
* Re: [PATCH 04/11] treewide: Convert struct kernel_param_ops initializers to DEFINE_KERNEL_PARAM_OPS
From: Petr Pavlu @ 2026-05-25 13:35 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521133326.2465264-4-kees@kernel.org>
On 5/21/26 3:33 PM, Kees Cook wrote:
> Using Coccinelle, rewrite every struct kernel_param_ops initializer that
> sets .get into a DEFINE_KERNEL_PARAM_OPS-family macro invocation,
> for example:
>
> @@
> declarer name DEFINE_KERNEL_PARAM_OPS;
> identifier OPS;
> expression SET, GET;
> @@
> - const struct kernel_param_ops OPS = {
> - .set = SET,
> - .get = GET,
> - };
> + DEFINE_KERNEL_PARAM_OPS(OPS, SET, GET);
>
> Using the macro for initialization means future changes can manipulate
> the struct layout and callback prototypes without having to change every
> initializer.
Nit: For consistency, I suggest also converting the few remaining
kernel_param_ops instances that specify only .set and no .get, such as
simdisk_param_ops_filename.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH 03/11] moduleparam: Add DEFINE_KERNEL_PARAM_OPS macro family
From: Petr Pavlu @ 2026-05-25 13:27 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521133326.2465264-3-kees@kernel.org>
On 5/21/26 3:33 PM, Kees Cook wrote:
> Add macros that define a struct kernel_param_ops initializer through a
> macro so the underlying field layout can evolve without touching every
> call site. Three variants cover the three cases:
>
> DEFINE_KERNEL_PARAM_OPS(name, set, get) // basic
> DEFINE_KERNEL_PARAM_OPS_NOARG(name, set, get) // set KERNEL_PARAM_OPS_FL_NOARG
> DEFINE_KERNEL_PARAM_OPS_FREE(name, set, get, free) // also set .free
>
> Callers prefix their own visibility qualifiers, e.g.:
>
> static DEFINE_KERNEL_PARAM_OPS(my_ops, my_set, my_get);
>
> Also update module_param_call() and STANDARD_PARAM_DEF() to use
> DEFINE_KERNEL_PARAM_OPS internally so the generated ops table will go
> through the same macro as everything else.
>
> Subsequent commits convert all open-coded struct kernel_param_ops
> definitions to use these macros, in preparation for migrating to a
> seq_buf .get API.
>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> include/linux/moduleparam.h | 36 ++++++++++++++++++++++++++++++++++--
> kernel/params.c | 6 ++----
> 2 files changed, 36 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index 075f28585074..26bf45b36d02 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -68,6 +68,39 @@ struct kernel_param_ops {
> void (*free)(void *arg);
> };
>
> +/*
> + * Define a const struct kernel_param_ops initializer. Callers prefix with
> + * any required visibility qualifiers (typically "static"):
> + *
> + * static DEFINE_KERNEL_PARAM_OPS(my_ops, my_set, my_get);
> + *
> + * Routing the @_set and @_get function pointers through the macro
> + * (rather than naming the struct fields at every call site) lets the
> + * field layout change in one place when callbacks are migrated to a
> + * new signature.
> + */
Nit: The newly introduced DEFINE_KERNEL_PARAM_OPS*() macros remain in
place at the end of the series after the migration is complete and this
comment is removed in patch 7. It would be helpful to describe in the
commit message why these macros are generally preferable to defining
kernel_param_ops instances directly.
I assume the motivation is that the structure is simple enough and using
macros then makes defining kernel_param_ops instances a bit more
concise. A minor disadvantage is that some analysis tools, such as
ctags, may no longer see the generated definition, but that is also the
case for DEFINE_MUTEX() and other similar macros.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v2 19/24] dyndbg,module: make proper substructs in _ddebug_info
From: Petr Pavlu @ 2026-05-25 9:24 UTC (permalink / raw)
To: Jim Cromie
Cc: Jonathan Corbet, Shuah Khan, Arnd Bergmann, Jason Baron,
Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
Andrew Morton, Shuah Khan, linux-doc, linux-kernel, linux-arch,
linux-modules, linux-kselftest, Louis Chauvet
In-Reply-To: <20260523-dd-maint-2-v2-19-b937312aa083@gmail.com>
On 5/23/26 9:14 AM, Jim Cromie wrote:
> recompose struct _ddebug_info, inserting proper sub-structs.
>
> The struct _ddebug_info has 2 pairs of _vec, num_##_vec fields, for
> descs and classes respectively. for_subvec() makes walking these
> vectors less cumbersome, now lets move those field pairs into their
> own "vec" structs: _ddebug_descs & _ddebug_class_maps, and re-compose
> struct _ddebug_info to contain them cleanly. This also lets us get
> rid of for_subvec()'s num_##_vec paste-up.
>
> Also recompose struct ddebug_table to contain a _ddebug_info. This
> reinforces its use as a cursor into relevant data for a builtin
> module, and access to the full _ddebug state for modules.
>
> NOTES:
>
> Fixup names: Normalize all struct names to "struct _ddebug_*"
> eliminating the minor/stupid variations created in classmaps-v1.
>
> Invariant: These vectors ref a contiguous subrange of __section memory
> in builtin/DATA or in loadable modules via mod->dyndbg_info; with
> guaranteed life-time for us.
>
> struct module contains a _ddebug_info field and module/main.c sets it
> up, so that gets adjusted rather obviously.
>
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> ---
> [...]
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index 46dd8d25a605..c2b6e70f2e77 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -2774,12 +2774,12 @@ static int find_module_sections(struct module *mod, struct load_info *info)
> pr_warn("%s: Ignoring obsolete parameters\n", mod->name);
>
> #ifdef CONFIG_DYNAMIC_DEBUG_CORE
> - mod->dyndbg_info.descs = section_objs(info, "__dyndbg",
> - sizeof(*mod->dyndbg_info.descs),
> - &mod->dyndbg_info.num_descs);
> - mod->dyndbg_info.classes = section_objs(info, "__dyndbg_classes",
> - sizeof(*mod->dyndbg_info.classes),
> - &mod->dyndbg_info.num_classes);
> + mod->dyndbg_info.descs.start = section_objs(info, "__dyndbg_descriptors",
> + sizeof(*mod->dyndbg_info.descs.start),
> + &mod->dyndbg_info.descs.len);
> + mod->dyndbg_info.maps.start = section_objs(info, "__dyndbg_class_maps",
> + sizeof(*mod->dyndbg_info.maps.start),
> + &mod->dyndbg_info.maps.len);
> #endif
>
> return 0;
The update changes the names of dyndbg sections that the module loader
looks up. However, the actual rename is not done until patch 24. It
would be good to clean this up to avoid potential bisection issues.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v2] genksyms: Support arm64 CRC32 hardware acceleration1~
From: Petr Pavlu @ 2026-05-25 9:09 UTC (permalink / raw)
To: Wentao Guan; +Cc: linux-kbuild, linux-kernel, linux-modules, masahiroy
In-Reply-To: <20260525080229.1570905-1-guanwentao@uniontech.com>
On 5/25/26 10:02 AM, Wentao Guan wrote:
>> Additionally, many distributions already switched to gendwarfksyms last
>> year. Unless someone provides a good reason to keep genksyms around,
>> I expect it will be deprecated soon and eventually removed. It would be
>> more valuable to show whether the same optimization is worthwhile for
>> gendwarfksyms.
> I see gendwarfksyms use crc32 from <zlib.h>, which from zlib1g-dev and zlib1g.
Ah, I forgot about this, so gendwarfksyms should already be well
optimized. I think that is the most important thing.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v2] genksyms: Support arm64 CRC32 hardware acceleration1~
From: Wentao Guan @ 2026-05-25 8:02 UTC (permalink / raw)
To: petr.pavlu
Cc: guanwentao, linux-kbuild, linux-kernel, linux-modules, masahiroy
In-Reply-To: <5d1b8b13-d590-497d-9185-609494135348@suse.com>
Hello Petr,
Thanks for your reply,
> Could you please provide measurements showing how this improves the
> runtime of genksyms and affects the overall kernel build time? Are
From my build kernel workload, genksyms perf report (record -g -F 99) show:
without patch:
- 7.83% 0.00% genksyms genksyms [.] _start
_start
- __libc_start_main
+ 3.19% yylex
1.81% find_symbol
0.92% is_reserved_word
0.62% free_list
+ 0.56% export_symbol
with patch:(find_symbol() and export_symbol() benifit from this):
- 7.12% 0.00% genksyms genksyms [.] _start
_start
- __libc_start_main
- 3.01% yylex
0.51% malloc
1.65% find_symbol
0.82% is_reserved_word
0.50% free_list
> CRC calculations actually a hot path in genksyms? I don't think it is
> worth complicating the genksyms code with architecture-specific
> optimizations unless there is a clear benefit.
Right.
> Additionally, many distributions already switched to gendwarfksyms last
> year. Unless someone provides a good reason to keep genksyms around,
> I expect it will be deprecated soon and eventually removed. It would be
> more valuable to show whether the same optimization is worthwhile for
> gendwarfksyms.
I see gendwarfksyms use crc32 from <zlib.h>, which from zlib1g-dev and zlib1g.
BRs
Wentao Guan
^ permalink raw reply
* Re: [PATCH v2] genksyms: Support arm64 CRC32 hardware acceleration
From: Petr Pavlu @ 2026-05-25 7:50 UTC (permalink / raw)
To: Wentao Guan; +Cc: masahiroy, linux-kernel, linux-kbuild, linux-modules
In-Reply-To: <20260525070344.1564886-1-guanwentao@uniontech.com>
+Cc: kbuild, modules
On 5/25/26 9:03 AM, Wentao Guan wrote:
> Use hardware 'crc32b' to partial_crc32_one() when support,
> it shows 2x speed up than crctab32 way.
>
> I think it will be scaled to more architecture.
Could you please provide measurements showing how this improves the
runtime of genksyms and affects the overall kernel build time? Are
CRC calculations actually a hot path in genksyms? I don't think it is
worth complicating the genksyms code with architecture-specific
optimizations unless there is a clear benefit.
Additionally, many distributions already switched to gendwarfksyms last
year. Unless someone provides a good reason to keep genksyms around,
I expect it will be deprecated soon and eventually removed. It would be
more valuable to show whether the same optimization is worthwhile for
gendwarfksyms.
--
Thanks,
Petr
>
> Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
> ---
> changelog:
> 1. remove change in partial_crc32(),
> for partial_crc32_one() already use crc32b.
>
> ---
> ---
> scripts/genksyms/genksyms.c | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/scripts/genksyms/genksyms.c b/scripts/genksyms/genksyms.c
> index 83e48670c2fcf..80b7797c842aa 100644
> --- a/scripts/genksyms/genksyms.c
> +++ b/scripts/genksyms/genksyms.c
> @@ -116,8 +116,40 @@ static const uint32_t crctab32[] = {
> 0x2d02ef8dU
> };
>
> +/*
> + * Architecture-specific CRC32 hardware acceleration.
> + */
> +static int crc32_hw_available;
> +
> +#ifdef __aarch64__
> +#include <sys/auxv.h>
> +#include <asm/hwcap.h>
> +
> +static void crc32_check_hw(void)
> +{
> + crc32_hw_available = (getauxval(AT_HWCAP) & HWCAP_CRC32) != 0;
> +}
> +
> +static inline uint32_t crc32_hw_byte(uint8_t c, uint32_t crc)
> +{
> + asm volatile(".arch_extension crc\n\t"
> + "crc32b %w0, %w0, %w1" : "+r"(crc) : "r"(c));
> + return crc;
> +}
> +
> +#else
> +static void crc32_check_hw(void)
> +{
> + crc32_hw_available = 0;
> +}
> +#endif
> +
> static uint32_t partial_crc32_one(uint8_t c, uint32_t crc)
> {
> +#if defined(__aarch64__)
> + if (__builtin_expect(crc32_hw_available, 0))
> + return crc32_hw_byte(c, crc);
> +#endif
> return crctab32[(crc ^ c) & 0xff] ^ (crc >> 8);
> }
>
> @@ -740,6 +772,8 @@ int main(int argc, char **argv)
> FILE *dumpfile = NULL, *ref_file = NULL;
> int o;
>
> + crc32_check_hw();
> +
> struct option long_opts[] = {
> {"debug", 0, 0, 'd'},
> {"warnings", 0, 0, 'w'},
^ permalink raw reply
* Re: DEPT (the dependency tracker) as AI review prompt?
From: Yunseong Kim @ 2026-05-23 15:04 UTC (permalink / raw)
To: Harry Yoo, Yunseong Kim
Cc: Byungchul Park, linux-kernel, kernel_team, torvalds,
damien.lemoal, linux-ide, adilger.kernel, linux-ext4, mingo,
peterz, will, tglx, rostedt, joel, sashal, daniel.vetter,
duyuyang, johannes.berg, tj, tytso, willy, david, amir73il,
gregkh, kernel-team, linux-mm, akpm, mhocko, minchan, hannes,
vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes, vbabka,
ngupta, linux-block, linux-fsdevel, jack, jlayton, dan.j.williams,
hch, djwong, dri-devel, rodrigosiqueiramelo, melissa.srw,
hamohammed.sa, harry.yoo, chris.p.wilson, gwan-gyeong.mun,
max.byungchul.park, boqun.feng, longman, yunseong.kim,
yeoreum.yun, netdev, matthew.brost, her0gyugyu, corbet,
catalin.marinas, bp, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux,
Chris Mason, Roman Gushchin, Josef Bacik
In-Reply-To: <0592b09b-a084-4d9d-bcbf-1b77e45226cf@kernel.org>
Hi Harry,
On 5/23/26 16:34, Harry Yoo wrote:
>
>
> On 5/23/26 11:00 PM, Yunseong Kim wrote:
>> I've previously experimented with running DEPT alongside syzkaller fuzzing,
>> and many hung tasks missed by lockdep are caught by DEPT, but the resulting
>> high volume of reports makes it easy for issues to get lost in the massive
>> log output. Sorting through that output manually is a huge bottleneck, so
>> leveraging a well-crafted AI prompt to triage the warnings and filter out
>> the false positives would be incredibly valuable.
>
> I mean both 1) detection of deadlock issues AND 2) false positive elimination with AI.
I completely agree. Implanting DEPT's model into an AI review prompt
is a great idea. As you suggested, the patterns we develop for the AI
could provide valuable feedback to enhance DEPT's itself.
> If the review prompt is only used to eliminate DEPT's false positives, I think that would be quite hard to get broad use.
>
> Someone would have to build out-of-tree DEPT, collect the reports, and then feed those back into the AI. I don't think building that kind of pipeline would actually work well in practice.
I also have a huge dept report of DEPT reports, and manually
reviewing all of them is makes me sigh. The constant kernel rebuilds
required for lockup testing every time are also quite expensive.
Thanks for the summary!
Best Regards,
Yunseong
^ permalink raw reply
* Re: DEPT (the dependency tracker) as AI review prompt?
From: Harry Yoo @ 2026-05-23 14:34 UTC (permalink / raw)
To: Yunseong Kim
Cc: Byungchul Park, linux-kernel, kernel_team, torvalds,
damien.lemoal, linux-ide, adilger.kernel, linux-ext4, mingo,
peterz, will, tglx, rostedt, joel, sashal, daniel.vetter,
duyuyang, johannes.berg, tj, tytso, willy, david, amir73il,
gregkh, kernel-team, linux-mm, akpm, mhocko, minchan, hannes,
vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes, vbabka,
ngupta, linux-block, linux-fsdevel, jack, jlayton, dan.j.williams,
hch, djwong, dri-devel, rodrigosiqueiramelo, melissa.srw,
hamohammed.sa, harry.yoo, chris.p.wilson, gwan-gyeong.mun,
max.byungchul.park, boqun.feng, longman, yunseong.kim,
yeoreum.yun, netdev, matthew.brost, her0gyugyu, corbet,
catalin.marinas, bp, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux,
Chris Mason, Roman Gushchin, Josef Bacik, Yunseong Kim
In-Reply-To: <CA+7O06GxeDLR9RcKDN2i-Rgc4kgzz6BfF4b0XAH4tFx=A723Nw@mail.gmail.com>
On 5/23/26 11:00 PM, Yunseong Kim wrote:
> I've previously experimented with running DEPT alongside syzkaller fuzzing,
> and many hung tasks missed by lockdep are caught by DEPT, but the resulting
> high volume of reports makes it easy for issues to get lost in the massive
> log output. Sorting through that output manually is a huge bottleneck, so
> leveraging a well-crafted AI prompt to triage the warnings and filter out
> the false positives would be incredibly valuable.
I mean both 1) detection of deadlock issues AND 2) false positive
elimination with AI.
If the review prompt is only used to eliminate DEPT's false positives, I
think that would be quite hard to get broad use.
Someone would have to build out-of-tree DEPT, collect the reports, and
then feed those back into the AI. I don't think building that kind of
pipeline would actually work well in practice.
--
Cheers,
Harry / Hyeonggon
^ permalink raw reply
* Re: DEPT (the dependency tracker) as AI review prompt? (was: DEPT v18)
From: Yunseong Kim @ 2026-05-23 14:00 UTC (permalink / raw)
To: Harry Yoo
Cc: Byungchul Park, linux-kernel, kernel_team, torvalds,
damien.lemoal, linux-ide, adilger.kernel, linux-ext4, mingo,
peterz, will, tglx, rostedt, joel, sashal, daniel.vetter,
duyuyang, johannes.berg, tj, tytso, willy, david, amir73il,
gregkh, kernel-team, linux-mm, akpm, mhocko, minchan, hannes,
vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes, vbabka,
ngupta, linux-block, linux-fsdevel, jack, jlayton, dan.j.williams,
hch, djwong, dri-devel, rodrigosiqueiramelo, melissa.srw,
hamohammed.sa, harry.yoo, chris.p.wilson, gwan-gyeong.mun,
max.byungchul.park, boqun.feng, longman, yunseong.kim, ysk,
yeoreum.yun, netdev, matthew.brost, her0gyugyu, corbet,
catalin.marinas, bp, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux,
Chris Mason, Roman Gushchin, Josef Bacik, Yunseong Kim
In-Reply-To: <6b2a816f-eb3b-4e0c-a024-ee2e3743eb04@kernel.org>
Hi Harry,
On Sat, May 23, 2026 at 2:33 PM Harry Yoo <harry@kernel.org> wrote:
>
> Can we start DEPT as an AI review prompt, by documenting DEPT's
> dependency tracking model and false positive elimination rules as a
> carefully crafted prompt?
>
> While DEPT can identify deadlock issues beyond lockdep's capabilities,
> it is hard to enable in automated testing; without fine-grained
> annotations it can produce a high rate of false positives, and verifying
> them requires significant human effort.
>
> The open source AI Review Prompt has locking.md file [1] that teaches
> the AI how to review locks and detect misuse.
>
> If we can write a review prompt for DEPT in a similar manner and have
> the AI do the deadlock detection and false positive elimination, I think
> we could identify those problems more effectively with much less human
> effort.
>
> [1]
> https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/locking.md
>
> --
> Cheers,
> Harry / Hyeonggon
I think this is an excellent idea, Harry.
I've previously experimented with running DEPT alongside syzkaller fuzzing,
and many hung tasks missed by lockdep are caught by DEPT, but the resulting
high volume of reports makes it easy for issues to get lost in the massive
log output. Sorting through that output manually is a huge bottleneck, so
leveraging a well-crafted AI prompt to triage the warnings and filter out
the false positives would be incredibly valuable.
Leveraging an AI prompt to triage these warnings would be incredibly valuable.
I'd be happy to help translate DEPT's tracking model into specific rules for
reducing false positives and establishing solid filtering patterns.
> On 12/5/25 4:18 PM, Byungchul Park wrote:
> > I'm happy to see that DEPT reported real problems in practice:
> >
> > https://lore.kernel.org/lkml/6383cde5-cf4b-facf-6e07-1378a485657d@I-love.SAKURA.ne.jp/
> > https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.park@lge.com/
> > https://lore.kernel.org/all/b6e00e77-4a8c-4e05-ab79-266bf05fcc2d@igalia.com/
> >
> > I’ve added documentation describing DEPT — this should help you
> > understand what DEPT is and how it works. You can use DEPT simply by
> > enabling CONFIG_DEPT and checking dmesg at runtime.
> > ---
> >
> > Hi Linus and folks,
> >
> > I’ve been developing a tool to detect deadlock possibilities by tracking
> > waits/events — rather than lock acquisition order — to cover all the
> > synchronization mechanisms. To summarize the design rationale, starting
> > from the problem statement, through analysis, to the solution:
> >
> > CURRENT STATUS
> > --------------
> > Lockdep tracks lock acquisition order to identify deadlock conditions.
> > Additionally, it tracks IRQ state changes — via {en,dis}able — to
> > detect cases where locks are acquired unintentionally during
> > interrupt handling.
> >
> > PROBLEM
> > -------
> > Waits and their associated events that are never reachable can
> > eventually lead to deadlocks. However, since Lockdep focuses solely
> > on lock acquisition order, it has inherent limitations when handling
> > waits and events.
> >
> > Moreover, by tracking only lock acquisition order, Lockdep cannot
> > properly handle read locks or cross-event scenarios — such as
> > wait_for_completion() and complete() — making it increasingly
> > inadequate as a general-purpose deadlock detection tool.
> >
> > SOLUTION
> > --------
> > Once again, waits and their associated events that are never
> > reachable can eventually lead to deadlocks. The new solution, DEPT,
> > focuses directly on waits and events. DEPT monitors waits and events,
> > and reports them when any become unreachable.
> >
> > DEPT provides:
> >
> > * Correct handling of read locks.
> > * Support for general waits and events.
> > * Continuous operation, even after multiple reports.
> > * Simple, intuitive annotation APIs.
> >
> > There are still false positives, and some are already being worked on
> > for suppression. Especially splitting the folio class into several
> > appropriate classes e.g. block device mapping class and regular file
> > mapping class, is currently under active development by me and Yeoreum
> > Yun.
> >> Anyway, these efforts will need to continue for a while, as we’ve seen
> > with lockdep over two decades. DEPT is tagged as EXPERIMENTAL in
> > Kconfig — meaning it’s not yet suitable for use as an automation tool.
> >
> > However, for those who are interested in using DEPT to analyze complex
> > synchronization patterns and extract dependency insights, DEPT would be
> > a great tool for the purpose.
Best regards,
Yunseong
^ permalink raw reply
* DEPT (the dependency tracker) as AI review prompt? (was: DEPT v18)
From: Harry Yoo @ 2026-05-23 12:32 UTC (permalink / raw)
To: Byungchul Park, linux-kernel
Cc: kernel_team, torvalds, damien.lemoal, linux-ide, adilger.kernel,
linux-ext4, mingo, peterz, will, tglx, rostedt, joel, sashal,
daniel.vetter, duyuyang, johannes.berg, tj, tytso, willy, david,
amir73il, gregkh, kernel-team, linux-mm, akpm, mhocko, minchan,
hannes, vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes,
vbabka, ngupta, linux-block, josef, linux-fsdevel, jack, jlayton,
dan.j.williams, hch, djwong, dri-devel, rodrigosiqueiramelo,
melissa.srw, hamohammed.sa, harry.yoo, chris.p.wilson,
gwan-gyeong.mun, max.byungchul.park, boqun.feng, longman,
yunseong.kim, ysk, yeoreum.yun, netdev, matthew.brost, her0gyugyu,
corbet, catalin.marinas, bp, x86, hpa, luto, sumit.semwal,
gustavo, christian.koenig, andi.shyti, arnd, lorenzo.stoakes,
Liam.Howlett, rppt, surenb, mcgrof, petr.pavlu, da.gomez,
samitolvanen, paulmck, frederic, neeraj.upadhyay, joelagnelf,
josh, urezki, mathieu.desnoyers, jiangshanlai, qiang.zhang,
juri.lelli, vincent.guittot, dietmar.eggemann, bsegall, mgorman,
vschneid, chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy,
anna, kees, bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux,
Chris Mason, Roman Gushchin, Josef Bacik
In-Reply-To: <20251205071855.72743-1-byungchul@sk.com>
Can we start DEPT as an AI review prompt, by documenting DEPT's
dependency tracking model and false positive elimination rules as a
carefully crafted prompt?
While DEPT can identify deadlock issues beyond lockdep's capabilities,
it is hard to enable in automated testing; without fine-grained
annotations it can produce a high rate of false positives, and verifying
them requires significant human effort.
The open source AI Review Prompt has locking.md file [1] that teaches
the AI how to review locks and detect misuse.
If we can write a review prompt for DEPT in a similar manner and have
the AI do the deadlock detection and false positive elimination, I think
we could identify those problems more effectively with much less human
effort.
[1]
https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/locking.md
--
Cheers,
Harry / Hyeonggon
On 12/5/25 4:18 PM, Byungchul Park wrote:
> I'm happy to see that DEPT reported real problems in practice:
>
> https://lore.kernel.org/lkml/6383cde5-cf4b-facf-6e07-1378a485657d@I-love.SAKURA.ne.jp/
> https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.park@lge.com/
> https://lore.kernel.org/all/b6e00e77-4a8c-4e05-ab79-266bf05fcc2d@igalia.com/
>
> I’ve added documentation describing DEPT — this should help you
> understand what DEPT is and how it works. You can use DEPT simply by
> enabling CONFIG_DEPT and checking dmesg at runtime.
> ---
>
> Hi Linus and folks,
>
> I’ve been developing a tool to detect deadlock possibilities by tracking
> waits/events — rather than lock acquisition order — to cover all the
> synchronization mechanisms. To summarize the design rationale, starting
> from the problem statement, through analysis, to the solution:
>
> CURRENT STATUS
> --------------
> Lockdep tracks lock acquisition order to identify deadlock conditions.
> Additionally, it tracks IRQ state changes — via {en,dis}able — to
> detect cases where locks are acquired unintentionally during
> interrupt handling.
>
> PROBLEM
> -------
> Waits and their associated events that are never reachable can
> eventually lead to deadlocks. However, since Lockdep focuses solely
> on lock acquisition order, it has inherent limitations when handling
> waits and events.
>
> Moreover, by tracking only lock acquisition order, Lockdep cannot
> properly handle read locks or cross-event scenarios — such as
> wait_for_completion() and complete() — making it increasingly
> inadequate as a general-purpose deadlock detection tool.
>
> SOLUTION
> --------
> Once again, waits and their associated events that are never
> reachable can eventually lead to deadlocks. The new solution, DEPT,
> focuses directly on waits and events. DEPT monitors waits and events,
> and reports them when any become unreachable.
>
> DEPT provides:
>
> * Correct handling of read locks.
> * Support for general waits and events.
> * Continuous operation, even after multiple reports.
> * Simple, intuitive annotation APIs.
>
> There are still false positives, and some are already being worked on
> for suppression. Especially splitting the folio class into several
> appropriate classes e.g. block device mapping class and regular file
> mapping class, is currently under active development by me and Yeoreum
> Yun.
>> Anyway, these efforts will need to continue for a while, as we’ve seen
> with lockdep over two decades. DEPT is tagged as EXPERIMENTAL in
> Kconfig — meaning it’s not yet suitable for use as an automation tool.
>
> However, for those who are interested in using DEPT to analyze complex
> synchronization patterns and extract dependency insights, DEPT would be
> a great tool for the purpose.
^ permalink raw reply
* Re: [PATCH v2 21/24] dyndbg: hoist classmap-filter-by-modname up to ddebug_add_module
From: sashiko-bot @ 2026-05-23 7:45 UTC (permalink / raw)
To: Jim Cromie; +Cc: linux-modules
In-Reply-To: <20260523-dd-maint-2-v2-21-b937312aa083@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch silently removes verbose debug logging (`v2pr_info` and `vpr_info`) that was previously emitted when module classmaps were successfully attached.
--
commit 6fc0ea29f4f01911b3505de6afab9a84131d7e51
Author: Jim Cromie <jim.cromie@gmail.com>
dyndbg: hoist classmap-filter-by-modname up to ddebug_add_module
This patch refactors the subrange filtering of module classmaps by moving
the logic from ddebug_attach_module_classes into a new macro named
dd_set_module_subrange. It also hoists the macro invocation into
ddebug_add_module to apply the filtering closer to initialization.
> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> index 4a9b9bc9efc5a..b877f4c6d778e 100644
> --- a/lib/dynamic_debug.c
> +++ b/lib/dynamic_debug.c
[ ... ]
> - if (!strcmp(cm->mod_name, dt->info.mod_name)) {
> - if (!nc) {
> - v2pr_info("start subrange, class[%d]: module:%s base:%d len:%d ty:%d\n",
> - i, cm->mod_name, cm->base, cm->length, cm->map_type);
> - dt->info.maps.start = cm;
> - }
> - nc++;
> - } else if (nc) {
> - /* end of matching classmaps */
> - break;
> - }
> - }
> - if (nc) {
> - dt->info.maps.len = nc;
> - vpr_info("module:%s attached %d classes\n", dt->info.mod_name, nc);
> - }
> -}
[ ... ]
> +#define dd_set_module_subrange(_i, _sp, _di, _vec) ({ \
> + struct _ddebug_info *__di = (_di); \
> + typeof(__di->_vec.start) __start = NULL; \
> + int __nc = 0; \
> + for_subvec(_i, _sp, __di, _vec) { \
> + if (!strcmp((_sp)->mod_name, __di->mod_name)) { \
> + if (!__nc++) \
> + __start = (_sp); \
> + } else if (__nc) { \
> + break; /* end of consecutive matches */ \
> + } \
> + } \
> + if (__nc) \
> + __di->_vec.start = __start; \
> + __di->_vec.len = __nc; \
> +})
[Severity: Low]
Was the removal of the verbose debug logging intentional?
The replaced ddebug_attach_module_classes function previously emitted
v2pr_info and vpr_info messages when module classmaps were successfully
attached. These diagnostic log messages appear to be completely removed
rather than migrated to the new macro.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523-dd-maint-2-v2-0-b937312aa083@gmail.com?part=21
^ permalink raw reply
* Re: [PATCH v2 19/24] dyndbg,module: make proper substructs in _ddebug_info
From: sashiko-bot @ 2026-05-23 7:45 UTC (permalink / raw)
To: Jim Cromie; +Cc: linux-modules
In-Reply-To: <20260523-dd-maint-2-v2-19-b937312aa083@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Module loader searches for incorrectly named dynamic debug sections, completely disabling dynamic debug for all loadable modules.
- [High] Built-in modules without class maps erroneously inherit all global system-wide class maps due to missing state reset.
- [Low] Renaming `struct ddebug_class_param` breaks compilation of external users like the DRM subsystem.
--
commit 647ef6a50774bbbe7f638336c42ae9d912b4ca12
Author: Jim Cromie <jim.cromie@gmail.com>
dyndbg,module: make proper substructs in _ddebug_info
This commit recomposes struct _ddebug_info by moving the descriptors and class
maps fields into new sub-structures struct _ddebug_descs and struct
_ddebug_class_maps. It also normalizes all related struct names to use a
_ddebug_ prefix.
> diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
> index a84dcc127e5a7..001bc84eadcab 100644
> --- a/include/linux/dynamic_debug.h
> +++ b/include/linux/dynamic_debug.h
[ ... ]
> @@ -81,21 +81,33 @@ struct ddebug_class_map {
> enum ddebug_class_map_type map_type;
> };
>
> -/* encapsulate linker provided built-in (or module) dyndbg data */
> +/*
> + * @_ddebug_info: gathers module/builtin dyndbg_* __sections together.
> + * For builtins, it is used as a cursor, with the inner structs
> + * marking sub-vectors of the builtin __sections in DATA.
> + */
> +struct _ddebug_descs {
> + struct _ddebug *start;
> + unsigned int len;
> +};
> +
> +struct _ddebug_class_maps {
> + struct _ddebug_class_map *start;
> + unsigned int len;
> +};
> +
> struct _ddebug_info {
> - struct _ddebug *descs;
> - struct ddebug_class_map *classes;
> - unsigned int num_descs;
> - unsigned int num_classes;
> + struct _ddebug_descs descs;
> + struct _ddebug_class_maps maps;
> };
>
> -struct ddebug_class_param {
> +struct _ddebug_class_param {
[Severity: Low]
Does renaming this structure break compilation for external users?
For example, the DRM subsystem directly references the old structure name in
drivers/gpu/drm/drm_print.c:
"static struct ddebug_class_param drm_debug_bitmap"
Failing to update these external users will result in a build failure for
configurations enabling DRM.
> union {
> u64 *bits;
> u64 *lvl;
> };
> char flags[8];
> - const struct ddebug_class_map *map;
> + const struct _ddebug_class_map *map;
> };
>
> /*
[ ... ]
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index 46dd8d25a6058..c2b6e70f2e773 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -2774,12 +2774,12 @@ static int find_module_sections(struct module *mod, struct load_info *info)
> pr_warn("%s: Ignoring obsolete parameters\n", mod->name);
>
> #ifdef CONFIG_DYNAMIC_DEBUG_CORE
> - mod->dyndbg_info.descs = section_objs(info, "__dyndbg",
> - sizeof(*mod->dyndbg_info.descs),
> - &mod->dyndbg_info.num_descs);
> - mod->dyndbg_info.classes = section_objs(info, "__dyndbg_classes",
> - sizeof(*mod->dyndbg_info.classes),
> - &mod->dyndbg_info.num_classes);
> + mod->dyndbg_info.descs.start = section_objs(info, "__dyndbg_descriptors",
> + sizeof(*mod->dyndbg_info.descs.start),
> + &mod->dyndbg_info.descs.len);
> + mod->dyndbg_info.maps.start = section_objs(info, "__dyndbg_class_maps",
> + sizeof(*mod->dyndbg_info.maps.start),
> + &mod->dyndbg_info.maps.len);
[Severity: High]
Does this correctly match the section names emitted by the linker?
It looks like the section names here were updated to "__dyndbg_descriptors"
and "__dyndbg_class_maps", but the macros like DECLARE_DYNDBG_CLASSMAP and
DEFINE_DYNAMIC_DEBUG_METADATA still emit to "__dyndbg" and "__dyndbg_classes".
Because the strings do not match, section_objs() will fail to find the
sections, setting their lengths to 0 and effectively discarding all
dynamic debug prints for loadable modules.
I see this regression is fixed later in the series by commit f9409a020a4bc
("dyndbg: improve section names").
> #endif
>
> return 0;
[ ... ]
> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> index 580aa258f902f..169b94ff6f8ed 100644
> --- a/lib/dynamic_debug.c
> +++ b/lib/dynamic_debug.c
[ ... ]
> @@ -1202,10 +1203,10 @@ static int ddebug_add_module(struct _ddebug_info *di, const char *modname)
> {
> struct ddebug_table *dt;
>
> - if (!di->num_descs)
> + if (!di->descs.len)
> return 0;
>
> - v3pr_info("add-module: %s %d sites\n", modname, di->num_descs);
> + v3pr_info("add-module: %s %d sites\n", modname, di->descs.len);
>
> dt = kzalloc_obj(*dt);
> if (dt == NULL) {
> @@ -1219,19 +1220,18 @@ static int ddebug_add_module(struct _ddebug_info *di, const char *modname)
> * this struct ddebug_table.
> */
> dt->mod_name = modname;
> - dt->ddebugs = di->descs;
> - dt->num_ddebugs = di->num_descs;
> + dt->info = *di;
[Severity: High]
Does this code leave dt->info.maps initialized to the entire system-wide
class maps array if the built-in module has no class maps?
In dynamic_debug_init(), the global _ddebug_info di is initialized with
.maps spanning the entire __dyndbg_classes section.
When this is copied via dt->info = *di here, dt->info.maps also spans
the entire section.
If the module has no class maps, ddebug_attach_module_classes() will run, but
the local variable nc remains 0. The block if (nc) at the end is skipped,
and dt->info.maps is never updated to reflect 0 length.
As a result, built-in modules without class maps falsely match unrelated
class maps from other built-in modules.
I see this regression is fixed later in the series by commit 6fc0ea29f4f01
("dyndbg: hoist classmap-filter-by-modname up to ddebug_add_module").
>
> INIT_LIST_HEAD(&dt->link);
>
> - if (di->classes && di->num_classes)
> + if (di->maps.len)
> ddebug_attach_module_classes(dt, di);
>
> mutex_lock(&ddebug_lock);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523-dd-maint-2-v2-0-b937312aa083@gmail.com?part=19
^ permalink raw reply
* Re: [PATCH v2 18/24] dyndbg: Upgrade class param storage to u64 for 64-bit classmaps
From: sashiko-bot @ 2026-05-23 7:42 UTC (permalink / raw)
To: Jim Cromie; +Cc: linux-modules
In-Reply-To: <20260523-dd-maint-2-v2-18-b937312aa083@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Buffer Overflow / Memory Corruption due to mismatched types in `ddebug_class_param`.
Pre-existing issues:
- [High] Undefined Behavior in `CLASSMAP_BITMASK` triggers shift overflow for 64-bit classmaps.
--
commit 58d2c659362026860249b9d71580382d0d84aa4e
Author: Jim Cromie <jim.cromie@gmail.com>
dyndbg: Upgrade class param storage to u64 for 64-bit classmaps
This commit upgrades the internal storage types in struct
ddebug_class_param from unsigned long to u64 pointers. This change
aims to safely support 64-bit classmaps across all architectures
without truncation.
> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> index e9481ef21825d..580aa258f902f 100644
> --- a/lib/dynamic_debug.c
> +++ b/lib/dynamic_debug.c
> @@ -661,7 +663,7 @@ static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
> /* stub to later conditionally add "$module." prefix where not already done */
> #define KP_NAME(kp) kp->name
>
> -#define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1)
> +#define CLASSMAP_BITMASK(width) ((1ULL << (width)) - 1)
[Severity: High]
This isn't a bug introduced by this patch, but does this macro invoke
undefined behavior if the classmap width reaches 64 bits?
If width is 64, shifting 1ULL by 64 is undefined behavior in C. On some
architectures like x86, the shift count is masked by 63, causing 1ULL << 64
to evaluate to 1ULL << 0 (which is 1). This would result in a bitmask of 0,
wiping out valid input bits and breaking the 64-bit feature.
[ ... ]
> @@ -696,24 +698,24 @@ static int param_set_dyndbg_module_classes(const char *instr,
> case DD_CLASS_TYPE_DISJOINT_BITS:
> /* expect bits. mask and warn if too many */
> if (inrep & ~CLASSMAP_BITMASK(map->length)) {
> - pr_warn("%s: input: 0x%lx exceeds mask: 0x%lx, masking\n",
> + pr_warn("%s: input: 0x%llx exceeds mask: 0x%llx, masking\n",
> KP_NAME(kp), inrep, CLASSMAP_BITMASK(map->length));
> inrep &= CLASSMAP_BITMASK(map->length);
> }
> - v2pr_info("bits:0x%lx > %s.%s\n", inrep, mod_name ?: "*", KP_NAME(kp));
> + v2pr_info("bits:0x%llx > %s.%s\n", inrep, mod_name ?: "*", KP_NAME(kp));
> totct += ddebug_apply_class_bitmap(dcp, &inrep, *dcp->bits, mod_name);
> *dcp->bits = inrep;
[Severity: High]
Can this cause memory corruption on 32-bit architectures?
The commit message notes that __drm_debug is not yet updated to u64,
meaning it remains an unsigned long. On 32-bit systems, unsigned long is 4
bytes. Since dcp->bits is now a u64 pointer, won't assigning inrep perform
an 8-byte write into a 4-byte allocation, corrupting adjacent memory?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523-dd-maint-2-v2-0-b937312aa083@gmail.com?part=18
^ permalink raw reply
* Re: [PATCH v2 05/24] vmlinux.lds.h: Fix ALIGN(8) omission causing NULL ptr on i386
From: sashiko-bot @ 2026-05-23 7:42 UTC (permalink / raw)
To: Jim Cromie; +Cc: linux-modules
In-Reply-To: <20260523-dd-maint-2-v2-5-b937312aa083@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The implicit 8-byte alignment added to `BOUNDED_SECTION` macros corrupts the `.notes` ELF section by injecting padding at the start, breaking `PT_NOTE` parsing.
- [Low] The patch fails to apply the `_ALIGNED` variant to `.BTF_ids`, violating the commit message's stated refactoring rules.
--
commit 8b6f5abfb8521b62106505848b2663ec04bac566
Author: Jim Cromie <jim.cromie@gmail.com>
Subject: vmlinux.lds.h: Fix ALIGN(8) omission causing NULL ptr on i386
This commit explicitly adds 8-byte alignment to BOUNDED_SECTION macros to
prevent unaligned section pointers. It also introduces _ALIGNED variants
for manually aligned sections and updates existing macros to use them.
Link: https://lore.kernel.org/lkml/177402491426.6181.12855763650074831089.b4-review@b4/
> diff --git a/include/asm-generic/bounded_sections.lds.h b/include/asm-generic/bounded_sections.lds.h
> index 268cdc34389b0..8ff3e3420f60a 100644
> --- a/include/asm-generic/bounded_sections.lds.h
> +++ b/include/asm-generic/bounded_sections.lds.h
[ ... ]
> -#define BOUNDED_SECTION_PRE_LABEL(_sec_, _label_, _BEGIN_, _END_) \
> +#define BOUNDED_SECTION_PRE_LABEL_ALIGNED(_sec_, _label_, _BEGIN_, _END_, _ALIGNED_) \
> + . = ALIGN(_ALIGNED_); \
> _BEGIN_##_label_ = .; \
> KEEP(*(_sec_)) \
> _END_##_label_ = .;
>
> -#define BOUNDED_SECTION_POST_LABEL(_sec_, _label_, _BEGIN_, _END_) \
> +#define BOUNDED_SECTION_PRE_LABEL(_sec_, _label_, _BEGIN_, _END_) \
> + BOUNDED_SECTION_PRE_LABEL_ALIGNED(_sec_, _label_, _BEGIN_, _END_, 8)
[Severity: High]
Does this implicit 8-byte alignment break the .notes ELF section by
injecting padding?
The NOTES macro in vmlinux.lds.h defines the .notes output section, which
inherits a 4-byte alignment from its input *(.note.*) sections. It often
follows RO_EXCEPTION_TABLE, which can end on a 4-byte boundary.
If the output section VMA is not 8-byte aligned, this new explicit
. = ALIGN(8) inside the BOUNDED_SECTION_BY macro will inject 4 bytes of
zero padding at the beginning of the .notes section.
This padding can be misinterpreted as an empty note header by external
tools and the kernel, breaking PT_NOTE parsing. Should the NOTES macro be
updated to use BOUNDED_SECTION_BY_ALIGNED(.note.*, _notes, 4)?
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 9c61dd083f26a..477333bdf3d35 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
[ ... ]
> @@ -650,7 +650,7 @@
> #define BTF \
> . = ALIGN(PAGE_SIZE); \
> .BTF : AT(ADDR(.BTF) - LOAD_OFFSET) { \
> - BOUNDED_SECTION_BY(.BTF, _BTF) \
> + BOUNDED_SECTION_BY_ALIGNED(.BTF, _BTF, PAGE_SIZE) \
> } \
> . = ALIGN(PAGE_SIZE); \
> .BTF_ids : AT(ADDR(.BTF_ids) - LOAD_OFFSET) { \
[Severity: Low]
The commit message states "update BOUNDED_SECTION uses inside . = ALIGN(x)
stanzas to use _ALIGNED variants".
Was .BTF_ids intentionally omitted from this rule?
It sits right below .BTF and also has an outer . = ALIGN(PAGE_SIZE), but
still uses the base BOUNDED_SECTION_BY macro. This doesn't cause functional
issues since it is already page-aligned, but it leaves the macro usage
inconsistent with the stated refactoring rules.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523-dd-maint-2-v2-0-b937312aa083@gmail.com?part=5
^ 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