kernel/linux.git/scripts/gdb/linux/constants.py.in, branch v6.6.132

scripts/gdb: fix interrupts.py after maple tree conversion

2025-07-17T16:35:15+00:00

commit a02b0cde8ee515ee0c8efd33e7fbe6830c282e69 upstream. In commit 721255b9826b ("genirq: Use a maple tree for interrupt descriptor management"), the irq_desc_tree was replaced with a sparse_irqs tree using a maple tree structure. Since the script looked for the irq_desc_tree symbol which is no longer available, no interrupts would be printed and the script output would not be useful anymore. In addition to looking up the correct symbol (sparse_irqs), a new module (mapletree.py) is added whose mtree_load() implementation is largely copied after the C version and uses the same variable and intermediate function names wherever possible to ensure that both the C and Python version be updated in the future. This restores the scripts' output to match that of /proc/interrupts. Link: https://lkml.kernel.org/r/20250625021020.1056930-1-florian.fainelli@broadcom.com Fixes: 721255b9826b ("genirq: Use a maple tree for interrupt descriptor management") Signed-off-by: Florian Fainelli Cc: Jan Kiszka Cc: Kieran Bingham Cc: Shanker Donthineni Cc: Thomas Gleinxer Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

scripts/gdb/vmalloc: disable on no-MMU

2023-11-28T17:20:05+00:00

commit 6620999f0d41e4fd6f047727936a964c3399d249 upstream. vmap_area does not exist on no-MMU, therefore the GDB scripts fail to load: Traceback (most recent call last): File "<...>/vmlinux-gdb.py", line 51, in import linux.vmalloc File "<...>/scripts/gdb/linux/vmalloc.py", line 14, in vmap_area_ptr_type = vmap_area_type.get_type().pointer() ^^^^^^^^^^^^^^^^^^^^^^^^^ File "<...>/scripts/gdb/linux/utils.py", line 28, in get_type self._type = gdb.lookup_type(self._name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ gdb.error: No struct type named vmap_area. To fix this, disable the command and add an informative error message if CONFIG_MMU is not defined, following the example of lx-slabinfo. Link: https://lkml.kernel.org/r/20231031202235.2655333-2-ben.wolsieffer@hefring.com Fixes: 852622bf3616 ("scripts/gdb/vmalloc: add vmallocinfo support") Signed-off-by: Ben Wolsieffer Cc: Jan Kiszka Cc: Kieran Bingham Cc: Kuan-Ying Lee Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

scripts/gdb: fix usage of MOD_TEXT not defined when CONFIG_MODULES=n

2023-11-20T10:59:24+00:00

[ Upstream commit 16501630bdeb107141a0139ddc33f92ab5582c6f ] MOD_TEXT is only defined if CONFIG_MODULES=y which lead to loading failure of the gdb scripts when kernel is built without CONFIG_MODULES=y: Reading symbols from vmlinux... Traceback (most recent call last): File "/foo/vmlinux-gdb.py", line 25, in import linux.constants File "/foo/scripts/gdb/linux/constants.py", line 14, in LX_MOD_TEXT = gdb.parse_and_eval("MOD_TEXT") ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ gdb.error: No symbol "MOD_TEXT" in current context. Add a conditional check on CONFIG_MODULES to fix this error. Link: https://lkml.kernel.org/r/20231031134848.119391-1-da.gomez@samsung.com Fixes: b4aff7513df3 ("scripts/gdb: use mem instead of core_layout to get the module address") Signed-off-by: Clément Léger Tested-by: Daniel Gomez Signed-off-by: Daniel Gomez Cc: Jan Kiszka Cc: Kieran Bingham Cc: Luis Chamberlain Cc: Pankaj Raghav Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

scripts/gdb/vmalloc: add vmallocinfo support

2023-08-21T20:46:23+00:00

This GDB script shows the vmallocinfo for user to analyze the vmalloc memory usage. Example output: 0xffff800008000000-0xffff800008009000 36864 pages=8 vmalloc 0xffff800008009000-0xffff80000800b000 8192 phys=0x8020000 ioremap 0xffff80000800b000-0xffff80000800d000 8192 pages=1 vmalloc 0xffff80000800d000-0xffff80000800f000 8192 pages=1 vmalloc 0xffff800008010000-0xffff80000ad30000 47316992 phys=0x40210000 vmap 0xffff80000ad30000-0xffff80000c1c0000 21561344 phys=0x42f30000 vmap 0xffff80000c1c0000-0xffff80000c370000 1769472 phys=0x443c0000 vmap 0xffff80000c370000-0xffff80000de90000 28442624 phys=0x44570000 vmap 0xffff80000de90000-0xffff80000f4c1000 23269376 phys=0x46090000 vmap 0xffff80000f4c1000-0xffff80000f4c3000 8192 pages=1 vmalloc 0xffff80000f4c3000-0xffff80000f4c5000 8192 pages=1 vmalloc 0xffff80000f4c5000-0xffff80000f4c7000 8192 pages=1 vmalloc Link: https://lkml.kernel.org/r/20230808083020.22254-9-Kuan-Ying.Lee@mediatek.com Signed-off-by: Kuan-Ying Lee Cc: AngeloGioacchino Del Regno Cc: Chinwen Chang Cc: Matthias Brugger Cc: Qun-Wei Lin Signed-off-by: Andrew Morton

scripts/gdb/slab: add slab support

2023-08-21T20:46:23+00:00

Add 'lx-slabinfo' and 'lx-slabtrace' support. This GDB scripts print slabinfo and slabtrace for user to analyze slab memory usage. Example output like below: (gdb) lx-slabinfo Pointer | name | active_objs | num_objs | objsize | objperslab | pagesperslab ------------------ | -------------------- | ------------ | ------------ | -------- | ----------- | ------------- 0xffff0000c59df480 | p9_req_t | 0 | 0 | 280 | 29 | 2 0xffff0000c59df280 | isp1760_qh | 0 | 0 | 160 | 25 | 1 0xffff0000c59df080 | isp1760_qtd | 0 | 0 | 184 | 22 | 1 0xffff0000c59dee80 | isp1760_urb_listite | 0 | 0 | 136 | 30 | 1 0xffff0000c59dec80 | asd_sas_event | 0 | 0 | 256 | 32 | 2 0xffff0000c59dea80 | sas_task | 0 | 0 | 448 | 36 | 4 0xffff0000c59de880 | bio-120 | 18 | 21 | 384 | 21 | 2 0xffff0000c59de680 | io_kiocb | 0 | 0 | 448 | 36 | 4 0xffff0000c59de480 | bfq_io_cq | 0 | 0 | 1504 | 21 | 8 0xffff0000c59de280 | bfq_queue | 0 | 0 | 720 | 22 | 4 0xffff0000c59de080 | mqueue_inode_cache | 1 | 28 | 1152 | 28 | 8 0xffff0000c59dde80 | v9fs_inode_cache | 0 | 0 | 832 | 39 | 8 ... (gdb) lx-slabtrace --cache_name kmalloc-1k 63 waste=16632/264 age=46856/46871/46888 pid=1 cpus=6, 0xffff800008720240 <__kmem_cache_alloc_node+236>: mov x22, x0 0xffff80000862a4fc : mov x21, x0 0xffff8000095d086c : mov x19, x0 0xffff8000095d0f98 : cmn x0, #0x1, lsl #12 0xffff80000c2677e8 : Cannot access memory at address 0xffff80000c2677e8 0xffff80000c265a10 : Cannot access memory at address 0xffff80000c265a10 0xffff80000c26d3c4 : Cannot access memory at address 0xffff80000c26d3c4 0xffff8000080161d4 : mov w21, w0 0xffff80000c1c1b58 : Cannot access memory at address 0xffff80000c1c1b58 0xffff80000acf1334 : bl 0xffff8000081ac040 0xffff800008018d00 : mrs x28, sp_el0 (gdb) lx-slabtrace --cache_name kmalloc-1k --free 428 age=4294958600 pid=0 cpus=0, Link: https://lkml.kernel.org/r/20230808083020.22254-8-Kuan-Ying.Lee@mediatek.com Signed-off-by: Kuan-Ying Lee Cc: AngeloGioacchino Del Regno Cc: Chinwen Chang Cc: Matthias Brugger Cc: Qun-Wei Lin Signed-off-by: Andrew Morton

scripts/gdb/page_owner: add page owner support

2023-08-21T20:46:23+00:00

This GDB script prints page owner information for user to analyze the memory usage or memory corruption issue. Example output from an aarch64 system: (gdb) lx-dump-page-owner --pfn 655360 page_owner tracks the page as allocated Page last allocated via order 0, gfp_mask: 0x8, pid: 1, tgid: 1 ("swapper/0\000\000\000\000\000\000"), ts 1295948880 ns, free_ts 1011852016 ns PFN: 655360, Flags: 0x3fffc0000000000 0xffff8000086ab964 : ldp x19, x20, [sp, #16] 0xffff80000862e4e0 : cbnz w22, 0xffff80000862e57c 0xffff8000086370c4 : mov x0, x27 0xffff8000086bc1cc : mov x24, x0 0xffff80000877d6d8 : mov w1, w0 0xffff8000082c8d18 : ldr x19, [sp, #16] 0xffff8000082ce0e8 : mov x19, x0 0xffff80000c1e41b4 <__dma_atomic_pool_init+172>: Cannot access memory at address 0xffff80000c1e41b4 0xffff80000c1e4298 : Cannot access memory at address 0xffff80000c1e4298 0xffff8000080161d4 : mov w21, w0 0xffff80000c1c1b50 : Cannot access memory at address 0xffff80000c1c1b50 0xffff80000acf87dc : bl 0xffff8000081ab100 0xffff800008018d00 : mrs x28, sp_el0 page last free stack trace: 0xffff8000086a6e8c : mov w2, w23 0xffff8000086aee1c : tst w0, #0xff 0xffff8000086af3f8 <__free_pages+292>: ldp x19, x20, [sp, #16] 0xffff80000c1f3214 : Cannot access memory at address 0xffff80000c1f3214 0xffff80000c20363c : Cannot access memory at address 0xffff80000c20363c 0xffff8000080161d4 : mov w21, w0 0xffff80000c1c1b50 : Cannot access memory at address 0xffff80000c1c1b50 0xffff80000acf87dc : bl 0xffff8000081ab100 0xffff800008018d00 : mrs x28, sp_el0 Link: https://lkml.kernel.org/r/20230808083020.22254-7-Kuan-Ying.Lee@mediatek.com Signed-off-by: Kuan-Ying Lee Cc: AngeloGioacchino Del Regno Cc: Chinwen Chang Cc: Matthias Brugger Cc: Qun-Wei Lin Signed-off-by: Andrew Morton

scripts/gdb/stackdepot: add stackdepot support

2023-08-21T20:46:22+00:00

Add support for printing the backtrace of stackdepot handle. This is the preparation patch for dumping page_owner, slabtrace usage. Link: https://lkml.kernel.org/r/20230808083020.22254-6-Kuan-Ying.Lee@mediatek.com Signed-off-by: Kuan-Ying Lee Cc: AngeloGioacchino Del Regno Cc: Chinwen Chang Cc: Matthias Brugger Cc: Qun-Wei Lin Signed-off-by: Andrew Morton

scripts/gdb/aarch64: add aarch64 page operation helper commands and configs

2023-08-21T20:46:22+00:00

1. Move page table debugging from mm.py to pgtable.py. 2. Add aarch64 kernel config and memory constants value. 3. Add below aarch64 page operation helper commands. page_to_pfn, page_to_phys, pfn_to_page, page_address, virt_to_phys, sym_to_pfn, pfn_to_kaddr, virt_to_page. 4. Only support CONFIG_SPARSEMEM_VMEMMAP=y now. Link: https://lkml.kernel.org/r/20230808083020.22254-5-Kuan-Ying.Lee@mediatek.com Signed-off-by: Kuan-Ying Lee Cc: AngeloGioacchino Del Regno Cc: Chinwen Chang Cc: Matthias Brugger Cc: Qun-Wei Lin Signed-off-by: Andrew Morton

scripts/gdb: fix 'lx-lsmod' show the wrong size

2023-08-18T17:18:58+00:00

'lsmod' shows total core layout size, so we need to sum up all the sections in core layout in gdb scripts. / # lsmod kasan_test 200704 0 - Live 0xffff80007f640000 Before patch: (gdb) lx-lsmod Address Module Size Used by 0xffff80007f640000 kasan_test 36864 0 After patch: (gdb) lx-lsmod Address Module Size Used by 0xffff80007f640000 kasan_test 200704 0 Link: https://lkml.kernel.org/r/20230710092852.31049-1-Kuan-Ying.Lee@mediatek.com Fixes: b4aff7513df3 ("scripts/gdb: use mem instead of core_layout to get the module address") Signed-off-by: Kuan-Ying Lee Reviewed-by: Pankaj Raghav Cc: AngeloGioacchino Del Regno Cc: Chinwen Chang Cc: Jan Kiszka Cc: Kieran Bingham Cc: Luis Chamberlain Cc: Matthias Brugger Cc: Qun-Wei Lin Signed-off-by: Andrew Morton

scripts/gdb: fix SB_* constants parsing

2023-06-19T20:19:32+00:00

--0000000000009a0c9905fd9173ad Content-Transfer-Encoding: 8bit After f15afbd34d8f ("fs: fix undefined behavior in bit shift for SB_NOUSER") the constants were changed from plain integers which LX_VALUE() can parse to constants using the BIT() macro which causes the following: Reading symbols from build/linux-custom/vmlinux...done. Traceback (most recent call last): File "/home/fainelli/work/buildroot/output/arm64/build/linux-custom/vmlinux-gdb.py", line 25, in import linux.constants File "/home/fainelli/work/buildroot/output/arm64/build/linux-custom/scripts/gdb/linux/constants.py", line 5 LX_SB_RDONLY = ((((1UL))) << (0)) Use LX_GDBPARSED() which does not suffer from that issue. f15afbd34d8f ("fs: fix undefined behavior in bit shift for SB_NOUSER") Link: https://lkml.kernel.org/r/20230607221337.2781730-1-florian.fainelli@broadcom.com Signed-off-by: Florian Fainelli Acked-by: Christian Brauner Cc: Hao Ge Cc: Jan Kiszka Cc: Kieran Bingham Cc: Luis Chamberlain Cc: Pankaj Raghav Signed-off-by: Andrew Morton