[PATCH 00/16] MAINTAINERS: Include GDB scripts under their relevant subsystems

[PATCH 00/16] MAINTAINERS: Include GDB scripts under their relevant subsystems

[Florian Fainelli]

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

[PATCH 01/16] MAINTAINERS: Include clk.py under COMMON CLK FRAMEWORK entry

[Florian Fainelli]

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

Re: [PATCH 01/16] MAINTAINERS: Include clk.py under COMMON CLK FRAMEWORK entry

[Stephen Boyd]

Quoting Florian Fainelli (2025-06-25 16:10:38)
> 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>
> ---

Applied to clk-next

[PATCH 02/16] MAINTAINERS: Include device.py under DRIVER CORE entry

[Florian Fainelli]

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

[PATCH 03/16] MAINTAINERS: Include genpd.py under GENERIC PM DOMAINS entry

[Florian Fainelli]

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

[PATCH 04/16] MAINTAINERS: Include radixtree.py under GENERIC RADIX TREE entry

[Florian Fainelli]

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

[PATCH 05/16] MAINTAINERS: Include interrupts.py under IRQ SUBSYSTEM entry

[Florian Fainelli]

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

[PATCH 06/16] MAINTAINERS: Include kasan.py under KASAN entry

[Florian Fainelli]

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

[PATCH 07/16] MAINTAINERS: Include mapletree.py under MAPLE TREE entry

[Florian Fainelli]

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

[PATCH 08/16] MAINTAINERS: Include GDB scripts under MEMORY MANAGEMENT entry

[Florian Fainelli]

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

Re: [PATCH 08/16] MAINTAINERS: Include GDB scripts under MEMORY MANAGEMENT entry

[David Hildenbrand]

On 26.06.25 01:10, Florian Fainelli wrote:
> 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

Probably they should go to the corresponding sub-sections. At least slab.py?

-- 
Cheers,

David / dhildenb

Re: [PATCH 08/16] MAINTAINERS: Include GDB scripts under MEMORY MANAGEMENT entry

[Florian Fainelli]

On 6/27/25 10:10, David Hildenbrand wrote:
> On 26.06.25 01:10, Florian Fainelli wrote:
>> 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
> 
> Probably they should go to the corresponding sub-sections. At least 
> slab.py?
> 

Sounds good, thanks!

-- 
Florian

[PATCH 09/16] MAINTAINERS: Include modules.py under MODULE SUPPORT entry

[Florian Fainelli]

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

[PATCH 10/16] MAINTAINERS: Include cpus.py under PER-CPU MEMORY ALLOCATOR entry

[Florian Fainelli]

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

[PATCH 11/16] MAINTAINERS: Include timerlist.py under POSIX CLOCKS and TIMERS entry

[Florian Fainelli]

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

[PATCH 12/16] MAINTAINERS: Include dmesg.py under PRINTK entry

[Florian Fainelli]

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

Re: [PATCH 12/16] MAINTAINERS: Include dmesg.py under PRINTK entry

[John Ogness]

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

Re: [PATCH 12/16] MAINTAINERS: Include dmesg.py under PRINTK entry

[Florian Fainelli]

On 6/26/25 01:43, John Ogness wrote:
> 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

Thanks, v2 coming up.
-- 
Florian

[PATCH 13/16] MAINTAINERS: Include proc.py under PROC FILESYSTEM entry

[Florian Fainelli]

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

[PATCH 14/16] MAINTAINERS: Include vmalloc.py under VMALLOC entry

[Florian Fainelli]

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

[PATCH 15/16] MAINTAINERS: Include xarray.py under XARRAY entry

[Florian Fainelli]

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

[PATCH 16/16] MAINTAINERS: Include vfs.py under FILESYSTEMS entry

[Florian Fainelli]

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

Re: [PATCH 00/16] MAINTAINERS: Include GDB scripts under their relevant subsystems

[Liam R. Howlett]

* 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

Re: [PATCH 00/16] MAINTAINERS: Include GDB scripts under their relevant subsystems

[Florian Fainelli]

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

Re: [PATCH 00/16] MAINTAINERS: Include GDB scripts under their relevant subsystems

[Jan Kara]

On Thu 26-06-25 09:39:36, Florian Fainelli wrote:
> 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 can see that it takes a lot of time to do a major update of a gdb
debugging script after some refactoring like this. OTOH mandating some gdb
scripts update is adding non-trivial amount of work to changes that are
already hard enough to do as is. And the obvious question is what is the
value? I've personally never used these gdb scripts and never felt a strong
need for something like that. People have various debugging aids (like BPF
scripts, gdb scripts, there's crash tool and drgn, and many more) lying
around.  I'm personally of an opinion that it is not a responsibility of
the person doing refactoring to make life easier for them or even fixing
them and I don't think that the fact that some debug aid is under
scripts/gdb/ directory is making it more special. So at least as far as I'm
concerned (VFS, fsnotify and other filesystem related stuff) I don't plan
on requiring updates to gdb scripts from people doing changes or otherwise
actively maintain them.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH 00/16] MAINTAINERS: Include GDB scripts under their relevant subsystems

[Florian Fainelli]

On 6/27/25 00:55, Jan Kara wrote:
> On Thu 26-06-25 09:39:36, Florian Fainelli wrote:
>> 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 can see that it takes a lot of time to do a major update of a gdb
> debugging script after some refactoring like this. OTOH mandating some gdb
> scripts update is adding non-trivial amount of work to changes that are
> already hard enough to do as is. 

This really should have been posted as RFC, because I can see how 
posting this as PATCH would be seen as coercing maintainers into taking 
those GDB scripts under their umbrella.

> And the obvious question is what is the
> value? I've personally never used these gdb scripts and never felt a strong
> need for something like that. People have various debugging aids (like BPF
> scripts, gdb scripts, there's crash tool and drgn, and many more) lying
> around. 

Those are valuable tools in the tool box, but GDB scripts can work when 
your only debug tool accessible is JTAG for instance, I appreciate this 
is typically miles away from what most of the kernel community does, but 
this is quite typical and common in embedded systems. When you operate 
in that environment, having a decent amount of debugger awareness of 
what is being debugged is immensely valuable in saving time.

> I'm personally of an opinion that it is not a responsibility of
> the person doing refactoring to make life easier for them or even fixing
> them and I don't think that the fact that some debug aid is under
> scripts/gdb/ directory is making it more special. 

That is really the question that I am trying to get answered with this 
patch series. IMHO as a subsystem maintainer it is not fair to be 
completely oblivious to scripts that live in the source tree, even if 
you are not aware of those.

 > So at least as far as I'm> concerned (VFS, fsnotify and other 
filesystem related stuff) I don't plan
> on requiring updates to gdb scripts from people doing changes or otherwise
> actively maintain them.

vfs.py script is beyond trivial, the largest and most complicated IMHO 
is mapletree.py which had to be recently developed to continue to 
support parsing the interrupt descriptor tree in the kernel, I can 
maintain that one now that I know a lot more than I ever wished I knew 
about maple trees. So really the burden is not as big as it may seem but 
it's fair not to be taking on more work as a maintainer, I get that.

Thanks for your feedback!
-- 
Florian

Re: [PATCH 00/16] MAINTAINERS: Include GDB scripts under their relevant subsystems

[Jan Kiszka]

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