* Re: [PATCH 00/16] MAINTAINERS: Include GDB scripts under their relevant subsystems
From: Jan Kiszka @ 2025-06-26 16:48 UTC (permalink / raw)
To: Liam R. Howlett, Florian Fainelli, linux-kernel, Kieran Bingham,
Michael Turquette, Stephen Boyd, Dennis Zhou, Tejun Heo,
Christoph Lameter, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Petr Mladek, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andrew Morton, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Kent Overstreet, Anna-Maria Behnsen,
Frederic Weisbecker, Alexander Viro, Christian Brauner, Jan Kara,
Uladzislau Rezki, Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich,
Etienne Buira, Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <fynmrmsglw4liexcb37ykutf724lh7zbibilcjpysbmvgtkmes@mtjrfkve4av7>
On 26.06.25 18:17, Liam R. Howlett wrote:
> * Florian Fainelli <florian.fainelli@broadcom.com> [250625 19:13]:
>> Linux has a number of very useful GDB scripts under scripts/gdb/linux/*
>> that provide OS awareness for debuggers and allows for debugging of a
>> variety of data structures (lists, timers, radix tree, mapletree, etc.)
>> as well as subsystems (clocks, devices, classes, busses, etc.).
>>
>> These scripts are typically maintained in isolation from the subsystem
>> that they parse the data structures and symbols of, which can lead to
>> people playing catch up with fixing bugs or updating the script to work
>> with updates made to the internal APIs/objects etc. Here are some
>> recents examples:
>>
>> https://lore.kernel.org/all/20250601055027.3661480-1-tony.ambardar@gmail.com/
>> https://lore.kernel.org/all/20250619225105.320729-1-florian.fainelli@broadcom.com/
>> https://lore.kernel.org/all/20250625021020.1056930-1-florian.fainelli@broadcom.com/
>>
>> This patch series is intentionally split such that each subsystem
>> maintainer can decide whether to accept the extra
>> review/maintenance/guidance that can be offered when GDB scripts are
>> being updated or added.
>
> I don't see why you think it was okay to propose this in the way you
> have gone about it. Looking at the mailing list, you've been around for
> a while.
>
> The file you are telling me about seems to be extremely new and I needed
> to pull akpm/mm-new to discover where it came from.. because you never
> Cc'ed me on the file you are asking me to own.
>
> I'm actually apposed to the filename you used for the script you want me
> to own.
>
> I consider myself a low-volume email maintainer and I get enough useless
> emails about apparent trivial fixes that end up causing significant
> damage if they are not dealt with. So I take care not to sign up for
> more time erosion from meaningful forward progress on tasks I hope to
> have high impact. I suspect you know that, but I don't know you so I
> don't want to assume.
>
> Is there anything else you might want to share to entice me to maintain
> this file? Perhaps there's a documentation pointer that shows how
> useful it is and why I should use it?
>
> Right now, I have no idea what that file does or how to even check if
> that file works today, so I cannot sign on to maintain it.
>
> If you want to depend on APIs, this should probably be generated in a
> way that enables updates. And if that's the case, then why even have a
> file at all and just generate it when needed? Or, at least, half
> generated and finished by hand?
>
> Maybe this is the case but scripts/gdb doesn't have any documentation in
> there, there's no Documentation/scripts or Documentation/gdb either.
>
> Can you please include more details on the uses of these files? Failing
> that, perhaps you could point to any documentation?
FWIW, I once wrote
Documentation/process/debugging/gdb-kernel-debugging.rst. Hope it didn't
age too much.
Jan
--
Siemens AG, Foundational Technologies
Linux Expert Center
^ permalink raw reply
* Re: [PATCH 00/16] MAINTAINERS: Include GDB scripts under their relevant subsystems
From: Florian Fainelli @ 2025-06-26 16:39 UTC (permalink / raw)
To: Liam R. Howlett, linux-kernel, Jan Kiszka, Kieran Bingham,
Michael Turquette, Stephen Boyd, Dennis Zhou, Tejun Heo,
Christoph Lameter, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Petr Mladek, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andrew Morton, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Kent Overstreet, Anna-Maria Behnsen,
Frederic Weisbecker, Alexander Viro, Christian Brauner, Jan Kara,
Uladzislau Rezki, Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich,
Etienne Buira, Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <fynmrmsglw4liexcb37ykutf724lh7zbibilcjpysbmvgtkmes@mtjrfkve4av7>
On 6/26/25 09:17, Liam R. Howlett wrote:
> * Florian Fainelli <florian.fainelli@broadcom.com> [250625 19:13]:
>> Linux has a number of very useful GDB scripts under scripts/gdb/linux/*
>> that provide OS awareness for debuggers and allows for debugging of a
>> variety of data structures (lists, timers, radix tree, mapletree, etc.)
>> as well as subsystems (clocks, devices, classes, busses, etc.).
>>
>> These scripts are typically maintained in isolation from the subsystem
>> that they parse the data structures and symbols of, which can lead to
>> people playing catch up with fixing bugs or updating the script to work
>> with updates made to the internal APIs/objects etc. Here are some
>> recents examples:
>>
>> https://lore.kernel.org/all/20250601055027.3661480-1-tony.ambardar@gmail.com/
>> https://lore.kernel.org/all/20250619225105.320729-1-florian.fainelli@broadcom.com/
>> https://lore.kernel.org/all/20250625021020.1056930-1-florian.fainelli@broadcom.com/
>>
>> This patch series is intentionally split such that each subsystem
>> maintainer can decide whether to accept the extra
>> review/maintenance/guidance that can be offered when GDB scripts are
>> being updated or added.
>
> I don't see why you think it was okay to propose this in the way you
> have gone about it. Looking at the mailing list, you've been around for
> a while.
This should probably have been posted as RFC rather than PATCH, but as I
indicate in the cover letter this is broken down to allow maintainers
like yourself to accept/reject
>
> The file you are telling me about seems to be extremely new and I needed
> to pull akpm/mm-new to discover where it came from.. because you never
> Cc'ed me on the file you are asking me to own.
Yes, that file is very new indeed, and my bad for not copying you on it.
I was not planning on burning an entire day worth of work to transition
the GDB scripts dumping the interrupt tree away from a radix tree to a
maple tree. All of which happens with the author of that conversion
having absolutely no idea that broke anything in the tree because very
few people know about the Python GDB scripts that Linux has. It is not
pleasant to be playing catch when it would have take maybe an extra
couple hours for someone intimately familiar with the maple tree to come
up with a suitable implementation replacement for mtree_load().
So having done it felt like there is a maintenance void that needs to be
filled, hence this patch set.
>
> I'm actually apposed to the filename you used for the script you want me
> to own.
Is there a different filename that you would prefer?
>
> I consider myself a low-volume email maintainer and I get enough useless
> emails about apparent trivial fixes that end up causing significant
> damage if they are not dealt with. So I take care not to sign up for
> more time erosion from meaningful forward progress on tasks I hope to
> have high impact. I suspect you know that, but I don't know you so I
> don't want to assume.
That seems entirely sane and thanks for being explicit about it.
>
> Is there anything else you might want to share to entice me to maintain
> this file? Perhaps there's a documentation pointer that shows how
> useful it is and why I should use it?
It can be as simple as spawning a QEMU instance:
qemu-system-x86_64 \
-s \
-cpu "max" \
-smp 4 \
-kernel ~/dev/linux/arch/x86/boot/bzImage \
-device pci-bridge,id=pci_bridge1,bus=pci.0,chassis_nr=1 \
-drive
file=debian.img,if=none,id=drive-virtio-disk0,format=qcow2 -device
virtio-blk-pci,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
\
-nographic \
-append "root=/dev/vda1 console=ttyS0,115200 mitigations=off" \
-net nic,model=e1000 -net tap,ifname=tap0
and in another terminal running GDB with:
gdb vmlinux -ex "target remote localhost:1234" -ex "lx-interruptlist"
to obtain a dump of /proc/interrupts which is effectively a replacement
for iterating over every interrupt descriptor in the system.
>
> Right now, I have no idea what that file does or how to even check if
> that file works today, so I cannot sign on to maintain it.
>
> If you want to depend on APIs, this should probably be generated in a
> way that enables updates. And if that's the case, then why even have a
> file at all and just generate it when needed? Or, at least, half
> generated and finished by hand?
As it stands today that is not happening, there is zero coordination and
people who care about GDB scripts just play catch up. But you raise a
good point, if we are to do that, then we should be able to target
C/Rust/Python/whatever, that seems like a bigger undertaking and I am
not clear whether the kernel community as a whole is looking for
transitioning over to something like this.
>
> Maybe this is the case but scripts/gdb doesn't have any documentation in
> there, there's no Documentation/scripts or Documentation/gdb either.
>
> Can you please include more details on the uses of these files? Failing
> that, perhaps you could point to any documentation?
See the two commands above, those should give you a good environment to
play with the various GDB scripts which are all prefix with "lx-".
Thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH 00/16] MAINTAINERS: Include GDB scripts under their relevant subsystems
From: Liam R. Howlett @ 2025-06-26 16:17 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andrew Morton, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Kent Overstreet, Anna-Maria Behnsen,
Frederic Weisbecker, Alexander Viro, Christian Brauner, Jan Kara,
Uladzislau Rezki, Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich,
Etienne Buira, Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
* Florian Fainelli <florian.fainelli@broadcom.com> [250625 19:13]:
> Linux has a number of very useful GDB scripts under scripts/gdb/linux/*
> that provide OS awareness for debuggers and allows for debugging of a
> variety of data structures (lists, timers, radix tree, mapletree, etc.)
> as well as subsystems (clocks, devices, classes, busses, etc.).
>
> These scripts are typically maintained in isolation from the subsystem
> that they parse the data structures and symbols of, which can lead to
> people playing catch up with fixing bugs or updating the script to work
> with updates made to the internal APIs/objects etc. Here are some
> recents examples:
>
> https://lore.kernel.org/all/20250601055027.3661480-1-tony.ambardar@gmail.com/
> https://lore.kernel.org/all/20250619225105.320729-1-florian.fainelli@broadcom.com/
> https://lore.kernel.org/all/20250625021020.1056930-1-florian.fainelli@broadcom.com/
>
> This patch series is intentionally split such that each subsystem
> maintainer can decide whether to accept the extra
> review/maintenance/guidance that can be offered when GDB scripts are
> being updated or added.
I don't see why you think it was okay to propose this in the way you
have gone about it. Looking at the mailing list, you've been around for
a while.
The file you are telling me about seems to be extremely new and I needed
to pull akpm/mm-new to discover where it came from.. because you never
Cc'ed me on the file you are asking me to own.
I'm actually apposed to the filename you used for the script you want me
to own.
I consider myself a low-volume email maintainer and I get enough useless
emails about apparent trivial fixes that end up causing significant
damage if they are not dealt with. So I take care not to sign up for
more time erosion from meaningful forward progress on tasks I hope to
have high impact. I suspect you know that, but I don't know you so I
don't want to assume.
Is there anything else you might want to share to entice me to maintain
this file? Perhaps there's a documentation pointer that shows how
useful it is and why I should use it?
Right now, I have no idea what that file does or how to even check if
that file works today, so I cannot sign on to maintain it.
If you want to depend on APIs, this should probably be generated in a
way that enables updates. And if that's the case, then why even have a
file at all and just generate it when needed? Or, at least, half
generated and finished by hand?
Maybe this is the case but scripts/gdb doesn't have any documentation in
there, there's no Documentation/scripts or Documentation/gdb either.
Can you please include more details on the uses of these files? Failing
that, perhaps you could point to any documentation?
...
Regards,
Liam
^ permalink raw reply
* Re: [PATCH 12/16] MAINTAINERS: Include dmesg.py under PRINTK entry
From: John Ogness @ 2025-06-26 8:43 UTC (permalink / raw)
To: Florian Fainelli, linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, Sergey Senozhatsky, Ulf Hansson,
Thomas Gleixner, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino,
Liam R. Howlett, Andrew Morton, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Kent Overstreet, Anna-Maria Behnsen,
Frederic Weisbecker, Alexander Viro, Christian Brauner, Jan Kara,
Uladzislau Rezki, Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich,
Etienne Buira, Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-13-florian.fainelli@broadcom.com>
On 2025-06-25, Florian Fainelli <florian.fainelli@broadcom.com> wrote:
> Include the GDB scripts file under scripts/gdb/linux/dmesg.py under the
> PRINTK subsystem since it parses internal data structures that depend
> upon that subsystem.
>
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 224825ddea83..0931440c890b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19982,6 +19982,7 @@ S: Maintained
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git
> F: include/linux/printk.h
> F: kernel/printk/
> +F: scripts/gdb/linux/dmesg.py
Note that Documentation/admin-guide/kdump/gdbmacros.txt also contains a
similar macro (dmesg). If something needs fixing in
scripts/gdb/linux/dmesg.py, it usually needs fixing in
Documentation/admin-guide/kdump/gdbmacros.txt as well.
So perhaps while at it, we can also add here:
F: Documentation/admin-guide/kdump/gdbmacros.txt
John Ogness
^ permalink raw reply
* [PATCH 03/16] MAINTAINERS: Include genpd.py under GENERIC PM DOMAINS entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/genpd.py under the
GENERIC PM DOMAINS subsystem since it parses internal data structures
that depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d92a78bf66e9..d51eeb1248be 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10163,6 +10163,7 @@ F: Documentation/devicetree/bindings/power/power?domain*
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git
F: drivers/pmdomain/
F: include/linux/pm_domain.h
+F: scripts/gdb/linux/genpd.py
GENERIC RADIX TREE
M: Kent Overstreet <kent.overstreet@linux.dev>
--
2.43.0
^ permalink raw reply related
* [PATCH 00/16] MAINTAINERS: Include GDB scripts under their relevant subsystems
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
Linux has a number of very useful GDB scripts under scripts/gdb/linux/*
that provide OS awareness for debuggers and allows for debugging of a
variety of data structures (lists, timers, radix tree, mapletree, etc.)
as well as subsystems (clocks, devices, classes, busses, etc.).
These scripts are typically maintained in isolation from the subsystem
that they parse the data structures and symbols of, which can lead to
people playing catch up with fixing bugs or updating the script to work
with updates made to the internal APIs/objects etc. Here are some
recents examples:
https://lore.kernel.org/all/20250601055027.3661480-1-tony.ambardar@gmail.com/
https://lore.kernel.org/all/20250619225105.320729-1-florian.fainelli@broadcom.com/
https://lore.kernel.org/all/20250625021020.1056930-1-florian.fainelli@broadcom.com/
This patch series is intentionally split such that each subsystem
maintainer can decide whether to accept the extra
review/maintenance/guidance that can be offered when GDB scripts are
being updated or added.
Thanks!
Florian Fainelli (16):
MAINTAINERS: Include clk.py under COMMON CLK FRAMEWORK entry
MAINTAINERS: Include device.py under DRIVER CORE entry
MAINTAINERS: Include genpd.py under GENERIC PM DOMAINS entry
MAINTAINERS: Include radixtree.py under GENERIC RADIX TREE entry
MAINTAINERS: Include interrupts.py under IRQ SUBSYSTEM entry
MAINTAINERS: Include kasan.py under KASAN entry
MAINTAINERS: Include mapletree.py under MAPLE TREE entry
MAINTAINERS: Include GDB scripts under MEMORY MANAGEMENT entry
MAINTAINERS: Include modules.py under MODULE SUPPORT entry
MAINTAINERS: Include cpus.py under PER-CPU MEMORY ALLOCATOR entry
MAINTAINERS: Include timerlist.py under POSIX CLOCKS and TIMERS entry
MAINTAINERS: Include dmesg.py under PRINTK entry
MAINTAINERS: Include proc.py under PROC FILESYSTEM entry
MAINTAINERS: Include vmalloc.py under VMALLOC entry
MAINTAINERS: Include xarray.py under XARRAY entry
MAINTAINERS: Include vfs.py under FILESYSTEMS entry
MAINTAINERS | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH 10/16] MAINTAINERS: Include cpus.py under PER-CPU MEMORY ALLOCATOR entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/cpus.py under the
PER-CPU MEMORY ALLOCATOR subsystem since it parses internal data
structures that depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7aca81142520..687f2b7cd382 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19525,6 +19525,7 @@ F: arch/*/include/asm/percpu.h
F: include/linux/percpu*.h
F: lib/percpu*.c
F: mm/percpu*.c
+F: scripts/gdb/linux/cpus.py
PER-TASK DELAY ACCOUNTING
M: Balbir Singh <bsingharora@gmail.com>
--
2.43.0
^ permalink raw reply related
* [PATCH 16/16] MAINTAINERS: Include vfs.py under FILESYSTEMS entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/vfs.py under the
FILESYSTEMS (VFS and infrastructure) subsystem since it parses internal
data structures that depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index a90d926c90a0..a292012a3ff1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9290,6 +9290,7 @@ F: include/uapi/linux/openat2.h
F: Documentation/driver-api/early-userspace/buffer-format.rst
F: init/do_mounts*
F: init/*initramfs*
+F: scripts/gdb/linux/vfs.py
FILESYSTEMS [EXPORTFS]
M: Chuck Lever <chuck.lever@oracle.com>
--
2.43.0
^ permalink raw reply related
* [PATCH 09/16] MAINTAINERS: Include modules.py under MODULE SUPPORT entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/modules.py under
the MODULE SUPPORT subsystem since it parses internal data structures
that depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 52b37196d024..7aca81142520 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16897,6 +16897,7 @@ F: include/linux/module*.h
F: kernel/module/
F: lib/test_kmod.c
F: lib/tests/module/
+F: scripts/gdb/linux/modules.py
F: scripts/module*
F: tools/testing/selftests/kmod/
F: tools/testing/selftests/module/
--
2.43.0
^ permalink raw reply related
* [PATCH 12/16] MAINTAINERS: Include dmesg.py under PRINTK entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/dmesg.py under the
PRINTK subsystem since it parses internal data structures that depend
upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 224825ddea83..0931440c890b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19982,6 +19982,7 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git
F: include/linux/printk.h
F: kernel/printk/
+F: scripts/gdb/linux/dmesg.py
PRINTK INDEXING
R: Chris Down <chris@chrisdown.name>
--
2.43.0
^ permalink raw reply related
* [PATCH 13/16] MAINTAINERS: Include proc.py under PROC FILESYSTEM entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/proc.py under the
PROC FILESYSTEM subsystem since it parses internal data structures that
depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0931440c890b..610828010cca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19998,6 +19998,7 @@ S: Maintained
F: Documentation/filesystems/proc.rst
F: fs/proc/
F: include/linux/proc_fs.h
+F: scripts/gdb/linux/proc.py
F: tools/testing/selftests/proc/
PROC SYSCTL
--
2.43.0
^ permalink raw reply related
* [PATCH 11/16] MAINTAINERS: Include timerlist.py under POSIX CLOCKS and TIMERS entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/timerlist.py under
the POSIX CLOCKS and TIMERS subsystem since it parses internal data
structures that depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 687f2b7cd382..224825ddea83 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19866,6 +19866,7 @@ F: include/trace/events/timer*
F: kernel/time/itimer.c
F: kernel/time/posix-*
F: kernel/time/namespace.c
+F: scripts/gdb/linux/timerlist.py
POWER MANAGEMENT CORE
M: "Rafael J. Wysocki" <rafael@kernel.org>
--
2.43.0
^ permalink raw reply related
* [PATCH 15/16] MAINTAINERS: Include xarray.py under XARRAY entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/xarray.py under the
XARRAY subsystem since it parses internal data structures that depend
upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8e86acd63739..a90d926c90a0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27087,6 +27087,7 @@ F: include/linux/xarray.h
F: lib/idr.c
F: lib/test_xarray.c
F: lib/xarray.c
+F: scripts/gdb/linux/xarray.py
F: tools/testing/radix-tree
XARRAY API [RUST]
--
2.43.0
^ permalink raw reply related
* [PATCH 14/16] MAINTAINERS: Include vmalloc.py under VMALLOC entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/vmalloc.py under
the VMALLOC subsystem since it parses internal data structures that
depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 610828010cca..8e86acd63739 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26577,6 +26577,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
F: include/linux/vmalloc.h
F: mm/vmalloc.c
F: lib/test_vmalloc.c
+F: scripts/gdb/linux/vmalloc.py
VME SUBSYSTEM
L: linux-kernel@vger.kernel.org
--
2.43.0
^ permalink raw reply related
* [PATCH 08/16] MAINTAINERS: Include GDB scripts under MEMORY MANAGEMENT entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/ that deal with
memory mamagenement code under the MEMORY MANAGEMENT subsystem since
they parses internal data structures that depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cad5d613cab0..52b37196d024 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15812,6 +15812,10 @@ F: include/linux/mmu_notifier.h
F: include/linux/pagewalk.h
F: include/trace/events/ksm.h
F: mm/
+F: scripts/gdb/linux/mm.py
+F: scripts/gdb/linux/page_owner.py
+F: scripts/gdb/linux/pgtable.py
+F: scripts/gdb/linux/slab.py
F: tools/mm/
F: tools/testing/selftests/mm/
N: include/linux/page[-_]*
--
2.43.0
^ permalink raw reply related
* [PATCH 05/16] MAINTAINERS: Include interrupts.py under IRQ SUBSYSTEM entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/interrupts.py under
the IRQ SUBSYSTEM entry since it parses internal data structures that
depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cfb0d60ef069..e1eda0d9d671 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12803,6 +12803,7 @@ F: include/linux/irqnr.h
F: include/linux/irqreturn.h
F: kernel/irq/
F: lib/group_cpus.c
+F: scripts/gdb/linux/interrupts.py
IRQCHIP DRIVERS
M: Thomas Gleixner <tglx@linutronix.de>
--
2.43.0
^ permalink raw reply related
* [PATCH 07/16] MAINTAINERS: Include mapletree.py under MAPLE TREE entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/mapletree.py under
the MAPLE TREE subsystem since it parses internal data structures that
depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d997995a92e3..cad5d613cab0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14525,6 +14525,7 @@ F: include/linux/maple_tree.h
F: include/trace/events/maple_tree.h
F: lib/maple_tree.c
F: lib/test_maple_tree.c
+F: scripts/gdb/linux/mapletree.py
F: tools/testing/radix-tree/maple.c
F: tools/testing/shared/linux/maple_tree.h
--
2.43.0
^ permalink raw reply related
* [PATCH 06/16] MAINTAINERS: Include kasan.py under KASAN entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/kasan.py under the
KASAN subsystem since it parses internal data structures that depend
upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e1eda0d9d671..d997995a92e3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13039,6 +13039,7 @@ F: include/linux/kasan*.h
F: lib/Kconfig.kasan
F: mm/kasan/
F: scripts/Makefile.kasan
+F: scripts/gdb/linux/kasan.py
KCONFIG
M: Masahiro Yamada <masahiroy@kernel.org>
--
2.43.0
^ permalink raw reply related
* [PATCH 04/16] MAINTAINERS: Include radixtree.py under GENERIC RADIX TREE entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/radix.py under the
GENERIC RADIX TREE subsystem since it parses internal data structures
that depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d51eeb1248be..cfb0d60ef069 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10171,6 +10171,7 @@ S: Supported
C: irc://irc.oftc.net/bcache
F: include/linux/generic-radix-tree.h
F: lib/generic-radix-tree.c
+F: scripts/gdb/linux/radixtree.py
GENERIC RESISTIVE TOUCHSCREEN ADC DRIVER
M: Eugen Hristev <eugen.hristev@microchip.com>
--
2.43.0
^ permalink raw reply related
* [PATCH 01/16] MAINTAINERS: Include clk.py under COMMON CLK FRAMEWORK entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/clk.py under the
COMMON CLK subsystem since it parses internal data structures that
depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2192d373610f..27521a01d462 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5987,6 +5987,7 @@ F: include/dt-bindings/clock/
F: include/linux/clk-pr*
F: include/linux/clk/
F: include/linux/of_clk.h
+F: scripts/gdb/linux/clk.py
F: rust/helpers/clk.c
F: rust/kernel/clk.rs
X: drivers/clk/clkdev.c
--
2.43.0
^ permalink raw reply related
* [PATCH 02/16] MAINTAINERS: Include device.py under DRIVER CORE entry
From: Florian Fainelli @ 2025-06-25 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Jan Kiszka, Kieran Bingham, Michael Turquette,
Stephen Boyd, Dennis Zhou, Tejun Heo, Christoph Lameter,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Ulf Hansson, Thomas Gleixner, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Liam R. Howlett, Andrew Morton,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Kent Overstreet, Anna-Maria Behnsen, Frederic Weisbecker,
Alexander Viro, Christian Brauner, Jan Kara, Uladzislau Rezki,
Matthew Wilcox, Kuan-Ying Lee, Ilya Leoshkevich, Etienne Buira,
Antonio Quartulli, Illia Ostapyshyn,
open list:COMMON CLK FRAMEWORK,
open list:PER-CPU MEMORY ALLOCATOR, open list:GENERIC PM DOMAINS,
open list:KASAN, open list:MAPLE TREE, open list:MODULE SUPPORT,
open list:PROC FILESYSTEM
In-Reply-To: <20250625231053.1134589-1-florian.fainelli@broadcom.com>
Include the GDB scripts file under scripts/gdb/linux/device.py under the
DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS subsystem since it parses
internal data structures that depend upon that subsystem.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 27521a01d462..d92a78bf66e9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7381,6 +7381,7 @@ F: rust/kernel/faux.rs
F: rust/kernel/platform.rs
F: samples/rust/rust_driver_platform.rs
F: samples/rust/rust_driver_faux.rs
+F: scripts/gdb/linux/device.py
DRIVERS FOR OMAP ADAPTIVE VOLTAGE SCALING (AVS)
M: Nishanth Menon <nm@ti.com>
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] codetag: Avoid unused alloc_tags sections/symbols
From: Suren Baghdasaryan @ 2025-06-25 16:07 UTC (permalink / raw)
To: Petr Pavlu
Cc: Andrew Morton, Kent Overstreet, Arnd Bergmann, Casey Chen,
linux-arch, linux-modules, linux-kernel
In-Reply-To: <20250618125037.53182-1-petr.pavlu@suse.com>
On Wed, Jun 18, 2025 at 5:50 AM Petr Pavlu <petr.pavlu@suse.com> wrote:
>
> With CONFIG_MEM_ALLOC_PROFILING=n, vmlinux and all modules unnecessarily
> contain the symbols __start_alloc_tags and __stop_alloc_tags, which define
> an empty range. In the case of modules, the presence of these symbols also
> forces the linker to create an empty .codetag.alloc_tags section.
>
> Update codetag.lds.h to make the data conditional on
> CONFIG_MEM_ALLOC_PROFILING.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
> Reviewed-by: Kent Overstreet <kent.overstreet@linux.dev>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Thanks!
Acked-by: Suren Baghdasaryan <surenb@google.com>
> ---
>
> Changes since v1 [1]:
> - Trivially rebased the patch on top of "alloc_tag: remove empty module tag
> section" [2].
>
> [1] https://lore.kernel.org/all/20250313143002.9118-1-petr.pavlu@suse.com/
> [2] https://lore.kernel.org/all/20250610162258.324645-1-cachen@purestorage.com/
>
> include/asm-generic/codetag.lds.h | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/include/asm-generic/codetag.lds.h b/include/asm-generic/codetag.lds.h
> index a45fe3d141a1..a14f4bdafdda 100644
> --- a/include/asm-generic/codetag.lds.h
> +++ b/include/asm-generic/codetag.lds.h
> @@ -2,6 +2,12 @@
> #ifndef __ASM_GENERIC_CODETAG_LDS_H
> #define __ASM_GENERIC_CODETAG_LDS_H
>
> +#ifdef CONFIG_MEM_ALLOC_PROFILING
> +#define IF_MEM_ALLOC_PROFILING(...) __VA_ARGS__
> +#else
> +#define IF_MEM_ALLOC_PROFILING(...)
> +#endif
> +
> #define SECTION_WITH_BOUNDARIES(_name) \
> . = ALIGN(8); \
> __start_##_name = .; \
> @@ -9,7 +15,7 @@
> __stop_##_name = .;
>
> #define CODETAG_SECTIONS() \
> - SECTION_WITH_BOUNDARIES(alloc_tags)
> + IF_MEM_ALLOC_PROFILING(SECTION_WITH_BOUNDARIES(alloc_tags))
>
> #define MOD_SEPARATE_CODETAG_SECTION(_name) \
> .codetag.##_name : { \
> @@ -22,6 +28,6 @@
> * unload them individually once unused.
> */
> #define MOD_SEPARATE_CODETAG_SECTIONS() \
> - MOD_SEPARATE_CODETAG_SECTION(alloc_tags)
> + IF_MEM_ALLOC_PROFILING(MOD_SEPARATE_CODETAG_SECTION(alloc_tags))
>
> #endif /* __ASM_GENERIC_CODETAG_LDS_H */
>
> base-commit: 52da431bf03b5506203bca27fe14a97895c80faf
> prerequisite-patch-id: acb6e2f6708cd75488806308bfecf682b2367dc9
> --
> 2.49.0
>
^ permalink raw reply
* [PATCH] gendwarfksyms: order -T symtypes output by name
From: Giuliano Procida @ 2025-06-25 9:52 UTC (permalink / raw)
To: Sami Tolvanen, Masahiro Yamada, Greg Kroah-Hartman
Cc: Giuliano Procida, linux-modules, linux-kbuild, linux-kernel
In-Reply-To: <20250623092350.3261118-2-gprocida@google.com>
When writing symtypes information, we iterate through the entire hash
table containing type expansions. The key order varies unpredictably
as new entries are added, making it harder to compare symtypes between
builds.
Resolve this by sorting the type expansions by name before output.
Signed-off-by: Giuliano Procida <gprocida@google.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
---
scripts/gendwarfksyms/types.c | 29 ++++++++++++++++++++++++++---
1 file changed, 26 insertions(+), 3 deletions(-)
[Adjusted the first line of the description. Added reviewer tags.
Added missing CC to linux-modules.]
diff --git a/scripts/gendwarfksyms/types.c b/scripts/gendwarfksyms/types.c
index 7bd459ea6c59..51c1471e8684 100644
--- a/scripts/gendwarfksyms/types.c
+++ b/scripts/gendwarfksyms/types.c
@@ -6,6 +6,8 @@
#define _GNU_SOURCE
#include <inttypes.h>
#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
#include <zlib.h>
#include "gendwarfksyms.h"
@@ -179,20 +181,41 @@ static int type_map_get(const char *name, struct type_expansion **res)
return -1;
}
+static int cmp_expansion_name(const void *p1, const void *p2)
+{
+ struct type_expansion *const *e1 = p1;
+ struct type_expansion *const *e2 = p2;
+
+ return strcmp((*e1)->name, (*e2)->name);
+}
+
static void type_map_write(FILE *file)
{
struct type_expansion *e;
struct hlist_node *tmp;
+ struct type_expansion **es;
+ size_t count = 0;
+ size_t i = 0;
if (!file)
return;
- hash_for_each_safe(type_map, e, tmp, hash) {
- checkp(fputs(e->name, file));
+ hash_for_each_safe(type_map, e, tmp, hash)
+ ++count;
+ es = xmalloc(count * sizeof(struct type_expansion *));
+ hash_for_each_safe(type_map, e, tmp, hash)
+ es[i++] = e;
+
+ qsort(es, count, sizeof(struct type_expansion *), cmp_expansion_name);
+
+ for (i = 0; i < count; ++i) {
+ checkp(fputs(es[i]->name, file));
checkp(fputs(" ", file));
- type_list_write(&e->expanded, file);
+ type_list_write(&es[i]->expanded, file);
checkp(fputs("\n", file));
}
+
+ free(es);
}
static void type_map_free(void)
--
2.50.0.714.g196bf9f422-goog
^ permalink raw reply related
* Re: [PATCH v13 2/6] rust: introduce module_param module
From: Andreas Hindborg @ 2025-06-24 11:57 UTC (permalink / raw)
To: Benno Lossin
Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Alice Ryhl, Masahiro Yamada,
Nathan Chancellor, Luis Chamberlain, Danilo Krummrich,
Nicolas Schier, Trevor Gross, Adam Bratschi-Kaye, rust-for-linux,
linux-kernel, linux-kbuild, Petr Pavlu, Sami Tolvanen,
Daniel Gomez, Simona Vetter, Greg KH, Fiona Behrens,
Daniel Almeida, linux-modules
In-Reply-To: <DAU0J3T0IEVM.2K7ZRQOVOHF8H@kernel.org>
"Benno Lossin" <lossin@kernel.org> writes:
> On Mon Jun 23, 2025 at 4:31 PM CEST, Andreas Hindborg wrote:
>> "Benno Lossin" <lossin@kernel.org> writes:
>>
>>> On Mon Jun 23, 2025 at 11:44 AM CEST, Andreas Hindborg wrote:
>>>> "Benno Lossin" <lossin@kernel.org> writes:
>>>>
>>>>> On Fri Jun 20, 2025 at 1:29 PM CEST, Andreas Hindborg wrote:
>>>>>> "Benno Lossin" <lossin@kernel.org> writes:
>>>>>>> On Thu Jun 12, 2025 at 3:40 PM CEST, Andreas Hindborg wrote:
>>>>>>>> +/// A wrapper for kernel parameters.
>>>>>>>> +///
>>>>>>>> +/// This type is instantiated by the [`module!`] macro when module parameters are
>>>>>>>> +/// defined. You should never need to instantiate this type directly.
>>>>>>>> +///
>>>>>>>> +/// Note: This type is `pub` because it is used by module crates to access
>>>>>>>> +/// parameter values.
>>>>>>>> +#[repr(transparent)]
>>>>>>>> +pub struct ModuleParamAccess<T> {
>>>>>>>> + data: core::cell::UnsafeCell<T>,
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> +// SAFETY: We only create shared references to the contents of this container,
>>>>>>>> +// so if `T` is `Sync`, so is `ModuleParamAccess`.
>>>>>>>> +unsafe impl<T: Sync> Sync for ModuleParamAccess<T> {}
>>>>>>>> +
>>>>>>>> +impl<T> ModuleParamAccess<T> {
>>>>>>>> + #[doc(hidden)]
>>>>>>>> + pub const fn new(value: T) -> Self {
>>>>>>>> + Self {
>>>>>>>> + data: core::cell::UnsafeCell::new(value),
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + /// Get a shared reference to the parameter value.
>>>>>>>> + // Note: When sysfs access to parameters are enabled, we have to pass in a
>>>>>>>> + // held lock guard here.
>>>>>>>> + pub fn get(&self) -> &T {
>>>>>>>> + // SAFETY: As we only support read only parameters with no sysfs
>>>>>>>> + // exposure, the kernel will not touch the parameter data after module
>>>>>>>> + // initialization.
>>>>>>>
>>>>>>> This should be a type invariant. But I'm having difficulty defining one
>>>>>>> that's actually correct: after parsing the parameter, this is written
>>>>>>> to, but when is that actually?
>>>>>>
>>>>>> For built-in modules it is during kernel initialization. For loadable
>>>>>> modules, it during module load. No code from the module will execute
>>>>>> before parameters are set.
>>>>>
>>>>> Gotcha and there never ever will be custom code that is executed
>>>>> before/during parameter setting (so code aside from code in `kernel`)?
>>>>>
>>>>>>> Would we eventually execute other Rust
>>>>>>> code during that time? (for example when we allow custom parameter
>>>>>>> parsing)
>>>>>>
>>>>>> I don't think we will need to synchronize because of custom parameter
>>>>>> parsing. Parameters are initialized sequentially. It is not a problem if
>>>>>> the custom parameter parsing code name other parameters, because they
>>>>>> are all initialized to valid values (as they are statics).
>>>>>
>>>>> If you have `&'static i64`, then the value at that reference is never
>>>>> allowed to change.
>>>>>
>>>>>>> This function also must never be `const` because of the following:
>>>>>>>
>>>>>>> module! {
>>>>>>> // ...
>>>>>>> params: {
>>>>>>> my_param: i64 {
>>>>>>> default: 0,
>>>>>>> description: "",
>>>>>>> },
>>>>>>> },
>>>>>>> }
>>>>>>>
>>>>>>> static BAD: &'static i64 = module_parameters::my_param.get();
>>>>>>>
>>>>>>> AFAIK, this static will be executed before loading module parameters and
>>>>>>> thus it makes writing to the parameter UB.
>>>>>>
>>>>>> As I understand, the static will be initialized by a constant expression
>>>>>> evaluated at compile time. I am not sure what happens when this is
>>>>>> evaluated in const context:
>>>>>>
>>>>>> pub fn get(&self) -> &T {
>>>>>> // SAFETY: As we only support read only parameters with no sysfs
>>>>>> // exposure, the kernel will not touch the parameter data after module
>>>>>> // initialization.
>>>>>> unsafe { &*self.data.get() }
>>>>>> }
>>>>>>
>>>>>> Why would that not be OK? I would assume the compiler builds a dependency graph
>>>>>> when initializing statics?
>>>>>
>>>>> Yes it builds a dependency graph, but that is irrelevant? The problem is
>>>>> that I can create a `'static` reference to the inner value *before* the
>>>>> parameter is written-to (as the static is initialized before the
>>>>> parameters).
>>>>
>>>> I see, I did not consider this situation. Thanks for pointing this out.
>>>>
>>>> Could we get around this without a lock maybe? If we change
>>>> `ModuleParamAccess::get` to take a closure instead:
>>>>
>>>> /// Call `func` with a reference to the parameter value stored in `Self`.
>>>> pub fn read(&self, func: impl FnOnce(&T)) {
>>>> // SAFETY: As we only support read only parameters with no sysfs
>>>> // exposure, the kernel will not touch the parameter data after module
>>>> // initialization.
>>>> let data = unsafe { &*self.data.get() };
>>>>
>>>> func(data)
>>>> }
>>>>
>>>> I think this would bound the lifetime of the reference passed to the
>>>> closure to the duration of the call, right?
>>>
>>> Yes that is correct. Now you can't assign the reference to a static.
>>> However, this API is probably very clunky to use, since you always have
>>> to create a closure etc.
>>>
>>> Since you mentioned in the other reply that one could spin up a thread
>>> and do something simultaneously, I don't think this is enough. You could
>>> have a loop spin over the new `read` function and read the value and
>>> then the write happens.
>>
>> Yes you are right, we have to treat it as if it could be written at any
>> point in time.
>>
>>> One way to fix this issue would be to use atomics to read the value and
>>> to not create a reference to it. So essentially have
>>>
>>> pub fn read(&self) -> T {
>>> unsafe { atomic_read_unsafe_cell(&self.data) }
>>> }
>>
>> That could work.
>>
>>> Another way would be to use a `Once`-like type (does that exist on the C
>>> side?) so a type that can be initialized once and then never changes.
>>> While it doesn't have a value set, we return some default value for the
>>> param and print a warning, when it's set, we just return the value. But
>>> this probably also requires atomics...
>>
>> I think atomic bool is not that far away. Either that, or we can lock.
>>
>>> Is parameter accessing used that often in hot paths? Can't you just copy
>>> the value into your `Module` struct?
>>
>> I don't imagine this being read in a hot path. If so, the user could
>> make a copy.
>
> That's good to know, then let's try to go for something simple.
>
> I don't think that we can just use a `Mutex<T>`, because we don't have a
> way to create it at const time... I guess we could have
>
> impl<T> Mutex<T>
> /// # Safety
> ///
> /// The returned value needs to be pinned and then `init` needs
> /// to be called before any other methods are called on this.
> pub unsafe const fn const_new() -> Self;
>
> pub unsafe fn init(&self);
> }
>
> But that seems like a bad idea, because where would we call the `init`
> function? That also needs to be synchronized...
Ah, that is unfortunate. The init function will not run before this, so
we would need a `Once` or an atomic anyway to initialize the lock.
I am not sure if we are allowed to sleep during this, I would have to
check. But then we could use a spin lock.
We will need the locking anyway, when we want to enable sysfs write
access to the parameters.
>
> Maybe we can just like you said use an atomic bool?
Sigh, I will have to check how far that series has come.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v13 2/6] rust: introduce module_param module
From: Benno Lossin @ 2025-06-23 15:20 UTC (permalink / raw)
To: Andreas Hindborg
Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Alice Ryhl, Masahiro Yamada,
Nathan Chancellor, Luis Chamberlain, Danilo Krummrich,
Nicolas Schier, Trevor Gross, Adam Bratschi-Kaye, rust-for-linux,
linux-kernel, linux-kbuild, Petr Pavlu, Sami Tolvanen,
Daniel Gomez, Simona Vetter, Greg KH, Fiona Behrens,
Daniel Almeida, linux-modules
In-Reply-To: <87v7om4jhq.fsf@kernel.org>
On Mon Jun 23, 2025 at 4:31 PM CEST, Andreas Hindborg wrote:
> "Benno Lossin" <lossin@kernel.org> writes:
>
>> On Mon Jun 23, 2025 at 11:44 AM CEST, Andreas Hindborg wrote:
>>> "Benno Lossin" <lossin@kernel.org> writes:
>>>
>>>> On Fri Jun 20, 2025 at 1:29 PM CEST, Andreas Hindborg wrote:
>>>>> "Benno Lossin" <lossin@kernel.org> writes:
>>>>>> On Thu Jun 12, 2025 at 3:40 PM CEST, Andreas Hindborg wrote:
>>>>>>> +/// A wrapper for kernel parameters.
>>>>>>> +///
>>>>>>> +/// This type is instantiated by the [`module!`] macro when module parameters are
>>>>>>> +/// defined. You should never need to instantiate this type directly.
>>>>>>> +///
>>>>>>> +/// Note: This type is `pub` because it is used by module crates to access
>>>>>>> +/// parameter values.
>>>>>>> +#[repr(transparent)]
>>>>>>> +pub struct ModuleParamAccess<T> {
>>>>>>> + data: core::cell::UnsafeCell<T>,
>>>>>>> +}
>>>>>>> +
>>>>>>> +// SAFETY: We only create shared references to the contents of this container,
>>>>>>> +// so if `T` is `Sync`, so is `ModuleParamAccess`.
>>>>>>> +unsafe impl<T: Sync> Sync for ModuleParamAccess<T> {}
>>>>>>> +
>>>>>>> +impl<T> ModuleParamAccess<T> {
>>>>>>> + #[doc(hidden)]
>>>>>>> + pub const fn new(value: T) -> Self {
>>>>>>> + Self {
>>>>>>> + data: core::cell::UnsafeCell::new(value),
>>>>>>> + }
>>>>>>> + }
>>>>>>> +
>>>>>>> + /// Get a shared reference to the parameter value.
>>>>>>> + // Note: When sysfs access to parameters are enabled, we have to pass in a
>>>>>>> + // held lock guard here.
>>>>>>> + pub fn get(&self) -> &T {
>>>>>>> + // SAFETY: As we only support read only parameters with no sysfs
>>>>>>> + // exposure, the kernel will not touch the parameter data after module
>>>>>>> + // initialization.
>>>>>>
>>>>>> This should be a type invariant. But I'm having difficulty defining one
>>>>>> that's actually correct: after parsing the parameter, this is written
>>>>>> to, but when is that actually?
>>>>>
>>>>> For built-in modules it is during kernel initialization. For loadable
>>>>> modules, it during module load. No code from the module will execute
>>>>> before parameters are set.
>>>>
>>>> Gotcha and there never ever will be custom code that is executed
>>>> before/during parameter setting (so code aside from code in `kernel`)?
>>>>
>>>>>> Would we eventually execute other Rust
>>>>>> code during that time? (for example when we allow custom parameter
>>>>>> parsing)
>>>>>
>>>>> I don't think we will need to synchronize because of custom parameter
>>>>> parsing. Parameters are initialized sequentially. It is not a problem if
>>>>> the custom parameter parsing code name other parameters, because they
>>>>> are all initialized to valid values (as they are statics).
>>>>
>>>> If you have `&'static i64`, then the value at that reference is never
>>>> allowed to change.
>>>>
>>>>>> This function also must never be `const` because of the following:
>>>>>>
>>>>>> module! {
>>>>>> // ...
>>>>>> params: {
>>>>>> my_param: i64 {
>>>>>> default: 0,
>>>>>> description: "",
>>>>>> },
>>>>>> },
>>>>>> }
>>>>>>
>>>>>> static BAD: &'static i64 = module_parameters::my_param.get();
>>>>>>
>>>>>> AFAIK, this static will be executed before loading module parameters and
>>>>>> thus it makes writing to the parameter UB.
>>>>>
>>>>> As I understand, the static will be initialized by a constant expression
>>>>> evaluated at compile time. I am not sure what happens when this is
>>>>> evaluated in const context:
>>>>>
>>>>> pub fn get(&self) -> &T {
>>>>> // SAFETY: As we only support read only parameters with no sysfs
>>>>> // exposure, the kernel will not touch the parameter data after module
>>>>> // initialization.
>>>>> unsafe { &*self.data.get() }
>>>>> }
>>>>>
>>>>> Why would that not be OK? I would assume the compiler builds a dependency graph
>>>>> when initializing statics?
>>>>
>>>> Yes it builds a dependency graph, but that is irrelevant? The problem is
>>>> that I can create a `'static` reference to the inner value *before* the
>>>> parameter is written-to (as the static is initialized before the
>>>> parameters).
>>>
>>> I see, I did not consider this situation. Thanks for pointing this out.
>>>
>>> Could we get around this without a lock maybe? If we change
>>> `ModuleParamAccess::get` to take a closure instead:
>>>
>>> /// Call `func` with a reference to the parameter value stored in `Self`.
>>> pub fn read(&self, func: impl FnOnce(&T)) {
>>> // SAFETY: As we only support read only parameters with no sysfs
>>> // exposure, the kernel will not touch the parameter data after module
>>> // initialization.
>>> let data = unsafe { &*self.data.get() };
>>>
>>> func(data)
>>> }
>>>
>>> I think this would bound the lifetime of the reference passed to the
>>> closure to the duration of the call, right?
>>
>> Yes that is correct. Now you can't assign the reference to a static.
>> However, this API is probably very clunky to use, since you always have
>> to create a closure etc.
>>
>> Since you mentioned in the other reply that one could spin up a thread
>> and do something simultaneously, I don't think this is enough. You could
>> have a loop spin over the new `read` function and read the value and
>> then the write happens.
>
> Yes you are right, we have to treat it as if it could be written at any
> point in time.
>
>> One way to fix this issue would be to use atomics to read the value and
>> to not create a reference to it. So essentially have
>>
>> pub fn read(&self) -> T {
>> unsafe { atomic_read_unsafe_cell(&self.data) }
>> }
>
> That could work.
>
>> Another way would be to use a `Once`-like type (does that exist on the C
>> side?) so a type that can be initialized once and then never changes.
>> While it doesn't have a value set, we return some default value for the
>> param and print a warning, when it's set, we just return the value. But
>> this probably also requires atomics...
>
> I think atomic bool is not that far away. Either that, or we can lock.
>
>> Is parameter accessing used that often in hot paths? Can't you just copy
>> the value into your `Module` struct?
>
> I don't imagine this being read in a hot path. If so, the user could
> make a copy.
That's good to know, then let's try to go for something simple.
I don't think that we can just use a `Mutex<T>`, because we don't have a
way to create it at const time... I guess we could have
impl<T> Mutex<T>
/// # Safety
///
/// The returned value needs to be pinned and then `init` needs
/// to be called before any other methods are called on this.
pub unsafe const fn const_new() -> Self;
pub unsafe fn init(&self);
}
But that seems like a bad idea, because where would we call the `init`
function? That also needs to be synchronized...
Maybe we can just like you said use an atomic bool?
---
Cheers,
Benno
^ 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