helpers: fix for_each_cpu to use new attributes #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
for_each_cpu is using old attributes "sizeof" and "size". Fix them to
use new ones.
Before patch:
>>> for x in for_each_online_cpu(prog): print(x)
...
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/home/naota/drgn/drgn/helpers/linux/cpumask.py", line 29, in for_each_cpu
word_bits = 8 * bits.type_.type.sizeof()
AttributeError: '_drgn.Type' object has no attribute 'sizeof'
After patch:
>>> for x in for_each_online_cpu(prog): print(x)
...
0
1
2
3
4
5
6
7
|
Thanks for the fix! This reminds me that I need to add tests for the helpers. |
peilin-ye
added a commit
to peilin-ye/drgn
that referenced
this pull request
Jan 7, 2022
Simply doing "drgn" segmentation-faults on my machine:
(gdb) bt
#0 apply_elf_rela_x86_64 (relocating=relocating@entry=0x7fc843650c90, r_offset=0, r_type=2, r_addend=0,
sym_value=<optimized out>) at ../../libdrgn/arch_x86_64.c:498
#1 0x00007fc88cbd523b in relocate_elf_section (platform=0x7fc843650c80, shdrnum=59, sh_addrs=0x7fc808000b20,
symtab_scn=<optimized out>, reloc_scn=0x17614c8, scn=<optimized out>) at ../../libdrgn/debug_info.c:761
osandov#2 relocate_elf_file (elf=<optimized out>) at ../../libdrgn/debug_info.c:865
osandov#3 drgn_debug_info_find_sections (module=<optimized out>) at ../../libdrgn/debug_info.c:883
osandov#4 drgn_debug_info_read_module (load=load@entry=0x7ffea9d70870, dindex_state=0x7ffea9d70810, head=0x163c6b0)
at ../../libdrgn/debug_info.c:970
osandov#5 0x00007fc88cbd5474 in drgn_debug_info_update_index._omp_fn.1 () at ../../libdrgn/debug_info.c:1037
osandov#6 0x00007fc88cb19769 in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
osandov#7 0x00007fc88cb21f00 in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
osandov#8 0x00007fc88cb1f7aa in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
osandov#9 0x00007fc88dfb7fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
osandov#10 0x00007fc88dafe4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Always returning NULL in libdrgn/debug_info.c:relocate_elf_file() fixes
the issue. I don't know, maybe it's a bug in drgn's implementation of
ELF relocation, but add this hack for now.
Signed-off-by: Peilin Ye <[email protected]>
brenns10
added a commit
to brenns10/drgn
that referenced
this pull request
May 10, 2023
The CTF type finder has previously used the "filename" parameter to indicate the kernel module in which a type should be searched. However, the default was to search vmlinux, which excluded all the types from modules. Normally in drgn, looking up a type by name would search for types from the vmlinux and modules. To make this behave correctly, factor out the basic logic of searching a CTF dictionary for a type with a given name into drgn_ctf_lookup_by_name(). Then, create a new helper drgn_ctf_find_type_name_all_dicts() which has the correct logic to be used in the case that no filename/module is specified: 1. Search vmlinux 2. Search modules Note that osandov#2 could still be improved. CTF contains type data for all modules, but ideally we would only search dictionaries related to modules which are actually loaded. We could also probably improve performance by using a cache for the most-recently-used CTF dict. With these two helpers, we can overhaul the CTF type finder's logic: when filename is provided, search just that module. Otherwise, use the all-modules logic described above. Signed-off-by: Stephen Brennan <[email protected]>
brenns10
added a commit
to brenns10/drgn
that referenced
this pull request
May 11, 2023
The CTF type finder has previously used the "filename" parameter to indicate the kernel module in which a type should be searched. However, the default was to search vmlinux, which excluded all the types from modules. Normally in drgn, looking up a type by name would search for types from the vmlinux and modules. To make this behave correctly, factor out the basic logic of searching a CTF dictionary for a type with a given name into drgn_ctf_lookup_by_name(). Then, create a new helper drgn_ctf_find_type_name_all_dicts() which has the correct logic to be used in the case that no filename/module is specified: 1. Search vmlinux 2. Search modules Note that osandov#2 could still be improved. CTF contains type data for all modules, but ideally we would only search dictionaries related to modules which are actually loaded. We could also probably improve performance by using a cache for the most-recently-used CTF dict. With these two helpers, we can overhaul the CTF type finder's logic: when filename is provided, search just that module. Otherwise, use the all-modules logic described above. Signed-off-by: Stephen Brennan <[email protected]>
brenns10
added a commit
to brenns10/drgn
that referenced
this pull request
May 31, 2023
The CTF type finder has previously used the "filename" parameter to indicate the kernel module in which a type should be searched. However, the default was to search vmlinux, which excluded all the types from modules. Normally in drgn, looking up a type by name would search for types from the vmlinux and modules. To make this behave correctly, factor out the basic logic of searching a CTF dictionary for a type with a given name into drgn_ctf_lookup_by_name(). Then, create a new helper drgn_ctf_find_type_name_all_dicts() which has the correct logic to be used in the case that no filename/module is specified: 1. Search vmlinux 2. Search modules Note that osandov#2 could still be improved. CTF contains type data for all modules, but ideally we would only search dictionaries related to modules which are actually loaded. We could also probably improve performance by using a cache for the most-recently-used CTF dict. With these two helpers, we can overhaul the CTF type finder's logic: when filename is provided, search just that module. Otherwise, use the all-modules logic described above. Signed-off-by: Stephen Brennan <[email protected]>
brenns10
added a commit
to brenns10/drgn
that referenced
this pull request
Jun 26, 2023
The CTF type finder has previously used the "filename" parameter to indicate the kernel module in which a type should be searched. However, the default was to search vmlinux, which excluded all the types from modules. Normally in drgn, looking up a type by name would search for types from the vmlinux and modules. To make this behave correctly, factor out the basic logic of searching a CTF dictionary for a type with a given name into drgn_ctf_lookup_by_name(). Then, create a new helper drgn_ctf_find_type_name_all_dicts() which has the correct logic to be used in the case that no filename/module is specified: 1. Search vmlinux 2. Search modules Note that osandov#2 could still be improved. CTF contains type data for all modules, but ideally we would only search dictionaries related to modules which are actually loaded. We could also probably improve performance by using a cache for the most-recently-used CTF dict. With these two helpers, we can overhaul the CTF type finder's logic: when filename is provided, search just that module. Otherwise, use the all-modules logic described above. Signed-off-by: Stephen Brennan <[email protected]>
brenns10
added a commit
to brenns10/drgn
that referenced
this pull request
Jun 29, 2023
The CTF type finder has previously used the "filename" parameter to indicate the kernel module in which a type should be searched. However, the default was to search vmlinux, which excluded all the types from modules. Normally in drgn, looking up a type by name would search for types from the vmlinux and modules. To make this behave correctly, factor out the basic logic of searching a CTF dictionary for a type with a given name into drgn_ctf_lookup_by_name(). Then, create a new helper drgn_ctf_find_type_name_all_dicts() which has the correct logic to be used in the case that no filename/module is specified: 1. Search vmlinux 2. Search modules Note that osandov#2 could still be improved. CTF contains type data for all modules, but ideally we would only search dictionaries related to modules which are actually loaded. We could also probably improve performance by using a cache for the most-recently-used CTF dict. With these two helpers, we can overhaul the CTF type finder's logic: when filename is provided, search just that module. Otherwise, use the all-modules logic described above. Signed-off-by: Stephen Brennan <[email protected]>
brenns10
added a commit
to brenns10/drgn
that referenced
this pull request
Aug 21, 2023
The CTF type finder has previously used the "filename" parameter to indicate the kernel module in which a type should be searched. However, the default was to search vmlinux, which excluded all the types from modules. Normally in drgn, looking up a type by name would search for types from the vmlinux and modules. To make this behave correctly, factor out the basic logic of searching a CTF dictionary for a type with a given name into drgn_ctf_lookup_by_name(). Then, create a new helper drgn_ctf_find_type_name_all_dicts() which has the correct logic to be used in the case that no filename/module is specified: 1. Search vmlinux 2. Search modules Note that osandov#2 could still be improved. CTF contains type data for all modules, but ideally we would only search dictionaries related to modules which are actually loaded. We could also probably improve performance by using a cache for the most-recently-used CTF dict. With these two helpers, we can overhaul the CTF type finder's logic: when filename is provided, search just that module. Otherwise, use the all-modules logic described above. Signed-off-by: Stephen Brennan <[email protected]>
brenns10
added a commit
to brenns10/drgn
that referenced
this pull request
Aug 22, 2023
The CTF type finder has previously used the "filename" parameter to indicate the kernel module in which a type should be searched. However, the default was to search vmlinux, which excluded all the types from modules. Normally in drgn, looking up a type by name would search for types from the vmlinux and modules. To make this behave correctly, factor out the basic logic of searching a CTF dictionary for a type with a given name into drgn_ctf_lookup_by_name(). Then, create a new helper drgn_ctf_find_type_name_all_dicts() which has the correct logic to be used in the case that no filename/module is specified: 1. Search vmlinux 2. Search modules Note that osandov#2 could still be improved. CTF contains type data for all modules, but ideally we would only search dictionaries related to modules which are actually loaded. We could also probably improve performance by using a cache for the most-recently-used CTF dict. With these two helpers, we can overhaul the CTF type finder's logic: when filename is provided, search just that module. Otherwise, use the all-modules logic described above. Signed-off-by: Stephen Brennan <[email protected]>
brenns10
added a commit
to brenns10/drgn
that referenced
this pull request
Sep 12, 2023
The CTF type finder has previously used the "filename" parameter to indicate the kernel module in which a type should be searched. However, the default was to search vmlinux, which excluded all the types from modules. Normally in drgn, looking up a type by name would search for types from the vmlinux and modules. To make this behave correctly, factor out the basic logic of searching a CTF dictionary for a type with a given name into drgn_ctf_lookup_by_name(). Then, create a new helper drgn_ctf_find_type_name_all_dicts() which has the correct logic to be used in the case that no filename/module is specified: 1. Search vmlinux 2. Search modules Note that osandov#2 could still be improved. CTF contains type data for all modules, but ideally we would only search dictionaries related to modules which are actually loaded. We could also probably improve performance by using a cache for the most-recently-used CTF dict. With these two helpers, we can overhaul the CTF type finder's logic: when filename is provided, search just that module. Otherwise, use the all-modules logic described above. Signed-off-by: Stephen Brennan <[email protected]>
brenns10
added a commit
to brenns10/drgn
that referenced
this pull request
Oct 20, 2023
The CTF type finder has previously used the "filename" parameter to indicate the kernel module in which a type should be searched. However, the default was to search vmlinux, which excluded all the types from modules. Normally in drgn, looking up a type by name would search for types from the vmlinux and modules. To make this behave correctly, factor out the basic logic of searching a CTF dictionary for a type with a given name into drgn_ctf_lookup_by_name(). Then, create a new helper drgn_ctf_find_type_name_all_dicts() which has the correct logic to be used in the case that no filename/module is specified: 1. Search vmlinux 2. Search modules Note that osandov#2 could still be improved. CTF contains type data for all modules, but ideally we would only search dictionaries related to modules which are actually loaded. We could also probably improve performance by using a cache for the most-recently-used CTF dict. With these two helpers, we can overhaul the CTF type finder's logic: when filename is provided, search just that module. Otherwise, use the all-modules logic described above. Signed-off-by: Stephen Brennan <[email protected]>
brenns10
added a commit
to brenns10/drgn
that referenced
this pull request
Oct 21, 2023
The CTF type finder has previously used the "filename" parameter to indicate the kernel module in which a type should be searched. However, the default was to search vmlinux, which excluded all the types from modules. Normally in drgn, looking up a type by name would search for types from the vmlinux and modules. To make this behave correctly, factor out the basic logic of searching a CTF dictionary for a type with a given name into drgn_ctf_lookup_by_name(). Then, create a new helper drgn_ctf_find_type_name_all_dicts() which has the correct logic to be used in the case that no filename/module is specified: 1. Search vmlinux 2. Search modules Note that osandov#2 could still be improved. CTF contains type data for all modules, but ideally we would only search dictionaries related to modules which are actually loaded. We could also probably improve performance by using a cache for the most-recently-used CTF dict. With these two helpers, we can overhaul the CTF type finder's logic: when filename is provided, search just that module. Otherwise, use the all-modules logic described above. Signed-off-by: Stephen Brennan <[email protected]>
imran-kn
added a commit
to imran-kn/drgn-work
that referenced
this pull request
Mar 18, 2024
These don't have tets cases so can't go under helpers.
I have put these under contrib so that they are available
for use.
python3 -m drgn -s vmlinux -c vmcore contrib/locks.py --help
usage: locks.py [-h] lock_type info_type [locks ...]
positional arguments:
lock_type type of lock i.e mutex. semaphore, rwsemaphore etc.
info_type "owner" or "waiter" or "all"
locks list of lock addresses
options:
-h, --help show this help message and exit
For example following command will give us call stack for owner
waiters of specified mutex(es):
python3 -m drgn -s vmlinux -c vmcore contrib/locks.py mutex all ffffffffc0143400
..................
Dumping call stack for waiter of mutex: ffffffffc0143400
call stack for pid: 215
#0 context_switch (kernel/sched/core.c:5238:2)
osandov#1 __schedule (kernel/sched/core.c:6551:8)
osandov#2 schedule (kernel/sched/core.c:6627:3)
osandov#3 schedule_preempt_disabled (kernel/sched/core.c:6686:2)
osandov#4 __mutex_lock_common (kernel/locking/mutex.c:679:3)
osandov#5 __mutex_lock (kernel/locking/mutex.c:747:9)
osandov#6 0xffffffffc01411f6
..................
call stack for pid: 216
#0 context_switch (kernel/sched/core.c:5238:2)
osandov#1 __schedule (kernel/sched/core.c:6551:8)
osandov#2 schedule (kernel/sched/core.c:6627:3)
osandov#3 schedule_preempt_disabled (kernel/sched/core.c:6686:2)
osandov#4 __mutex_lock_common (kernel/locking/mutex.c:679:3)
osandov#5 __mutex_lock (kernel/locking/mutex.c:747:9)
osandov#6 0xffffffffc014112b
..................
Dumping call stack for owner of mutex: ffffffffc0143400
call stack for pid: 214
#0 delay_tsc (arch/x86/lib/delay.c:79:3)
osandov#1 0xffffffffc0141308
..................
Signed-off-by: Imran Khan <[email protected]>
imran-kn
added a commit
to imran-kn/drgn-work
that referenced
this pull request
Mar 18, 2024
python3 -m drgn -s vmlinux -c vmcore contrib/locks.py --help usage: locks.py [-h] lock_type info_type [locks ...] positional arguments: lock_type type of lock i.e mutex. semaphore, rwsemaphore etc. info_type "owner" or "waiter" or "all" locks list of lock addresses options: -h, --help show this help message and exit For example following command will give us call stack for owner waiters of specified mutex(es): python3 -m drgn -s vmlinux -c vmcore contrib/locks.py semaphore waiter ffffffffc0097340 Dumping call stack for waiter(s) of semaphore: ffffffffc0097340 call stack for pid: 1178 #0 context_switch (kernel/sched/core.c:2811:2) osandov#1 __schedule (kernel/sched/core.c:3387:8) osandov#2 schedule (kernel/sched/core.c:3431:3) osandov#3 schedule_timeout (kernel/time/timer.c:1724:3) osandov#4 __down_common (kernel/locking/semaphore.c:221:13) osandov#5 __down (kernel/locking/semaphore.c:238:2) osandov#6 down (kernel/locking/semaphore.c:62:3) osandov#7 0xffffffffc0095045 .................. call stack for pid: 1180 #0 context_switch (kernel/sched/core.c:2811:2) osandov#1 __schedule (kernel/sched/core.c:3387:8) osandov#2 schedule (kernel/sched/core.c:3431:3) osandov#3 schedule_timeout (kernel/time/timer.c:1724:3) osandov#4 __down_common (kernel/locking/semaphore.c:221:13) osandov#5 __down (kernel/locking/semaphore.c:238:2) osandov#6 down (kernel/locking/semaphore.c:62:3) osandov#7 0xffffffffc0095045 ............. Signed-off-by: Imran Khan <[email protected]>
imran-kn
added a commit
to imran-kn/drgn-work
that referenced
this pull request
Mar 18, 2024
Add some ready-made helpers for rwsem and make the script
modular so that options can be added/removed for one lock
type, independently from other lock types.
Some example of using the script have been given below:
python3 -m drgn -s vmlinux -c vmcore-1 contrib/locks.py -h
usage: drgn script to dump lock information [-h] {mutex,semaphore,rwsem} ...
options:
-h, --help show this help message and exit
subcommands:
{mutex,semaphore,rwsem}
mutex get mutex info.
semaphore get semaphore info.
rwsem get read-write semaphore info.
python3 -m drgn -s vmlinux -c vmcore-1 contrib/locks.py semaphore -h
usage: drgn script to dump lock information semaphore [-h] [--info | --waiter-list | --waiter-callstack] [locks ...]
positional arguments:
locks list of lock addresses
options:
-h, --help show this help message and exit
--info dump given semaphore's info like waiter(s) etc.
--waiter-list provide a list, of waiters of given semaphore(s)
--waiter-callstack provide callstack of all waiters of given semaphore(s)
python3 -m drgn -s vmlinux -c vmcore contrib/locks.py semaphore --waiter-list ffffffffc0097340
The waiters of semaphore: ffffffffc0097340 are as follows:
(struct task_struct *)0xffff992afc618000 pid: 1178 state: D
(struct task_struct *)0xffff992afc7ae200 pid: 1181 state: D
(struct task_struct *)0xffff992afc61ee40 pid: 1179 state: D
(struct task_struct *)0xffff992afc619880 pid: 1180 state: D
python3 -m drgn -s vmlinux -c vmcore-1 contrib/locks.py semaphore --waiter-list ffffffffc0262340
The waiters of semaphore: ffffffffc0262340 are as follows:
(struct task_struct *)0xffff96c3fc6ec980 pid: 1178 state: S
(struct task_struct *)0xffff96c3fc6eee40 pid: 1177 state: S
(struct task_struct *)0xffff96c3fc5a55c0 pid: 1175 state: S
(struct task_struct *)0xffff96c3fc6ee200 pid: 1176 state: S
python3 -m drgn -s vmlinux -c vmcore-1 contrib/locks.py semaphore --waiter-callstack ffffffffc0262340
Dumping call stack for waiter(s) of semaphore: ffffffffc0262340
call stack for pid: 1178
#0 context_switch (kernel/sched/core.c:2811:2)
osandov#1 __schedule (kernel/sched/core.c:3387:8)
osandov#2 schedule (kernel/sched/core.c:3431:3)
osandov#3 schedule_timeout (kernel/time/timer.c:1724:3)
osandov#4 __down_common (kernel/locking/semaphore.c:221:13)
osandov#5 __down_interruptible (kernel/locking/semaphore.c:243:9)
osandov#6 down_interruptible (kernel/locking/semaphore.c:85:12)
osandov#7 0xffffffffc0260045
.....................
call stack for pid: 1176
#0 context_switch (kernel/sched/core.c:2811:2)
osandov#1 __schedule (kernel/sched/core.c:3387:8)
osandov#2 schedule (kernel/sched/core.c:3431:3)
osandov#3 schedule_timeout (kernel/time/timer.c:1724:3)
osandov#4 __down_common (kernel/locking/semaphore.c:221:13)
osandov#5 __down_interruptible (kernel/locking/semaphore.c:243:9)
osandov#6 down_interruptible (kernel/locking/semaphore.c:85:12)
osandov#7 0xffffffffc0260045
call stack for pid: 1176
.....................
python3 -m drgn -s vmlinux -c vmcore-1 contrib/locks.py mutex -h
usage: drgn script to dump lock information mutex [-h] [--info | --waiter-list | --waiter-callstack | --owner-callstack] [locks ...]
positional arguments:
locks list of lock addresses
options:
-h, --help show this help message and exit
--info dump given mutex's info like owner, waiter(s) etc.
--waiter-list provide a list, of waiters of given mutex(es)
--waiter-callstack provide callstack of all waiters of given mutex(es)
--owner-callstack provide callstack of owner of given mutex(es)
python3 -m drgn -s vmlinux -c vmcore contrib/locks.py mutex --info ffffffffc0143400
mutex: ffffffffc0143400 is owned by (struct task_struct *)0xffffa1fe42393900 pid: 214 state: R
The waiters of mutex: ffffffffc0143400 are as follows:
(struct task_struct *)0xffffa1fe42395580 pid: 215 state: D
(struct task_struct *)0xffffa1fe42a58000 pid: 216 state: D
(struct task_struct *)0xffffa1fe42389c80 pid: 217 state: D
python3 -m drgn -s vmlinux -c vmcore contrib/locks.py mutex --waiter-list ffffffffc0143400
The waiters of mutex: ffffffffc0143400 are as follows:
(struct task_struct *)0xffffa1fe42395580 pid: 215 state: D
(struct task_struct *)0xffffa1fe42a58000 pid: 216 state: D
(struct task_struct *)0xffffa1fe42389c80 pid: 217 state: D
python3 -m drgn -s vmlinux -c vmcore contrib/locks.py mutex --waiter-callstack ffffffffc0143400
Dumping call stack for waiter of mutex: ffffffffc0143400
call stack for pid: 215
#0 context_switch (kernel/sched/core.c:5238:2)
osandov#1 __schedule (kernel/sched/core.c:6551:8)
osandov#2 schedule (kernel/sched/core.c:6627:3)
osandov#3 schedule_preempt_disabled (kernel/sched/core.c:6686:2)
osandov#4 __mutex_lock_common (kernel/locking/mutex.c:679:3)
osandov#5 __mutex_lock (kernel/locking/mutex.c:747:9)
osandov#6 0xffffffffc01411f6
........................
python3 -m drgn -s vmlinux -c vmcore-multiple-readers contrib/locks.py rwsem -h
usage: drgn script to dump lock information rwsem [-h] [--info | --waiter-list | --waiter-callstack | --owner-callstack] [locks ...]
positional arguments:
locks list of lock addresses
options:
-h, --help show this help message and exit
--info dump given rwsem's info like owner, waiter(s) etc.
--waiter-list provide a list, of waiters of given rwsem(s)
--waiter-callstack provide callstack of all waiters of given rwsem(s)
--owner-callstack provide callstack of owner of given rwsem(s)
python3 -m drgn -s vmlinux -c vmcore-reader-writer-reader-reader contrib/locks.py rwsem --info ffffffffc036d3c0
rwsem: ffffffffc036d3c0 is owned by one or more readers.
The waiters of rwsem are as follows:
(struct task_struct *)0xffff9e593d4e3100: (pid)1175: type: down_write state: D
(struct task_struct *)0xffff9e593d4e1880: (pid)1176: type: down_read state: D
(struct task_struct *)0xffff9e593d4e6200: (pid)1177: type: down_read state: D
python3 -m drgn -s vmlinux -c vmcore-reader-writer-reader-reader contrib/locks.py rwsem --waiter-callstack ffffffffc036d3c0
Dumping call stack for waiter of rwsem: ffffffffc036d3c0
call stack for pid: 1175
#0 context_switch (kernel/sched/core.c:2814:2)
osandov#1 __schedule (kernel/sched/core.c:3389:8)
osandov#2 schedule (kernel/sched/core.c:3433:3)
osandov#3 __rwsem_down_write_failed_common (kernel/locking/rwsem-xadd.c:588:4)
osandov#4 call_rwsem_down_write_failed+0x13/0x1f (arch/x86/lib/rwsem.S:105)
osandov#5 __down_write (./arch/x86/include/asm/rwsem.h:126:2)
osandov#6 down_write (kernel/locking/rwsem.c:56:2)
osandov#7 0xffffffffc036b2b6
................................
python3 -m drgn -s vmlinux -c vmcore-writer-reader-reader-reader contrib/locks.py rwsem --info ffffffffc02033c0
rwsem: ffffffffc02033c0 owned by writer (struct task_struct *)0xffff9162fdb58c40 (pid)1173 (state)R
The waiters of rwsem are as follows:
(struct task_struct *)0xffff9162fdb5ee40: (pid)1174: type: down_read state: D
(struct task_struct *)0xffff9162fd8355c0: (pid)1175: type: down_read state: D
(struct task_struct *)0xffff9162fd836200: (pid)1176: type: down_read state: D
For newer kernels number of read owners can be obtained:
python3 -m drgn -s vmlinux -c vmcore-multiple-readers contrib/locks.py rwsem --info ffffffffc00c9340
rwsem: ffffffffc00c9340 is owned by 2 reader(s).
There are no waiters for rwsem: ffffffffc00c9340.
Signed-off-by: Imran Khan <[email protected]>
imran-kn
added a commit
to imran-kn/drgn-work
that referenced
this pull request
Mar 18, 2024
For example: python3 -m drgn -s vmlinux -c vmcore-writer-reader-reader-reader contrib/locks.py rwsem --spinner-callstack ffffffffc03083c0 rwsem: ffffffffc03083c0 has 1 spinners and their call-stack is as follows: call stack for pid: 239 #0 __read_once_size (./include/linux/compiler.h:268:2) osandov#1 arch_atomic64_read (./arch/x86/include/asm/atomic64_64.h:22:9) osandov#2 atomic64_read (./include/asm-generic/atomic-instrumented.h:837:9) osandov#3 atomic_long_read (./include/asm-generic/atomic-long.h:28:9) osandov#4 rwsem_owner_flags (kernel/locking/rwsem.c:298:24) osandov#5 rwsem_spin_on_owner (kernel/locking/rwsem.c:737:9) osandov#6 rwsem_optimistic_spin (kernel/locking/rwsem.c:812:17) osandov#7 rwsem_down_read_slowpath (kernel/locking/rwsem.c:1018:6) osandov#8 __down_read_killable (kernel/locking/rwsem.c:1366:14) osandov#9 down_read_killable (kernel/locking/rwsem.c:1532:6) osandov#10 0xffffffffc030622c ................. Signed-off-by: Imran Khan <[email protected]>
imran-kn
added a commit
to imran-kn/drgn-work
that referenced
this pull request
Mar 18, 2024
For example: python3 -m drgn -s vmlinux -c vmcore-1 contrib/locks.py mutex --spinner-callstack ffffffffc02af340 mutex: ffffffffc02af340 has 4 spinners and their call-stack is as follows: call stack for pid: 250 #0 __read_once_size (./include/linux/compiler.h:268:2) osandov#1 osq_lock (kernel/locking/osq_lock.c:137:10) osandov#2 mutex_optimistic_spin (kernel/locking/mutex.c:667:8) osandov#3 __mutex_lock_common (kernel/locking/mutex.c:971:6) osandov#4 __mutex_lock (kernel/locking/mutex.c:1109:9) osandov#5 0xffffffffc02ad045 ...................... call stack for pid: 251 #0 __read_once_size (./include/linux/compiler.h:268:2) osandov#1 osq_lock (kernel/locking/osq_lock.c:137:10) osandov#2 mutex_optimistic_spin (kernel/locking/mutex.c:667:8) osandov#3 __mutex_lock_common (kernel/locking/mutex.c:971:6) osandov#4 __mutex_lock (kernel/locking/mutex.c:1109:9) osandov#5 0xffffffffc02ad045 ..................... call stack for pid: 248 #0 __read_once_size (./include/linux/compiler.h:268:2) osandov#1 osq_lock (kernel/locking/osq_lock.c:137:10) osandov#2 mutex_optimistic_spin (kernel/locking/mutex.c:667:8) osandov#3 __mutex_lock_common (kernel/locking/mutex.c:971:6) osandov#4 __mutex_lock (kernel/locking/mutex.c:1109:9) osandov#5 0xffffffffc02ad045 ..................... call stack for pid: 249 #0 __read_once_size (./include/linux/compiler.h:268:2) osandov#1 arch_atomic64_read (./arch/x86/include/asm/atomic64_64.h:22:9) osandov#2 atomic64_read (./include/asm-generic/atomic-instrumented.h:837:9) osandov#3 atomic_long_read (./include/asm-generic/atomic-long.h:28:9) osandov#4 __mutex_owner (kernel/locking/mutex.c:75:32) osandov#5 mutex_spin_on_owner (kernel/locking/mutex.c:566:9) osandov#6 mutex_optimistic_spin (kernel/locking/mutex.c:683:8) osandov#7 __mutex_lock_common (kernel/locking/mutex.c:971:6) osandov#8 __mutex_lock (kernel/locking/mutex.c:1109:9) osandov#9 0xffffffffc02ad045 .................... Signed-off-by: Imran Khan <[email protected]>
kylee0215
added a commit
to kylee0215/drgn
that referenced
this pull request
Sep 4, 2024
Sample output: Page allocated via order 0, gfp_mask: 0x140cca, pid: 74, tgid: 74 (b'kworker/u32:2'), ts 1189257596 ns, free_ts 0 ns PFN: 262203, Flags: 0x3fffe000004003c #0 set_page_owner (./include/linux/page_owner.h:32:3) osandov#1 post_alloc_hook (mm/page_alloc.c:1502:2) osandov#2 prep_new_page (mm/page_alloc.c:1510:2) osandov#3 get_page_from_freelist (mm/page_alloc.c:3489:4) osandov#4 __alloc_pages_noprof (mm/page_alloc.c:4747:9) osandov#5 alloc_pages_mpol_noprof (mm/mempolicy.c:2263:9) osandov#6 folio_alloc_mpol_noprof (mm/mempolicy.c:2281:9) osandov#7 shmem_alloc_folio (mm/shmem.c:1726:10) osandov#8 shmem_alloc_and_add_folio (mm/shmem.c:1786:11) osandov#9 shmem_get_folio_gfp (mm/shmem.c:2192:10) osandov#10 shmem_get_folio (mm/shmem.c:2297:9) osandov#11 shmem_write_begin (mm/shmem.c:2902:8) osandov#12 generic_perform_write (mm/filemap.c:4019:12) osandov#13 shmem_file_write_iter (mm/shmem.c:3078:8) osandov#14 __kernel_write_iter (fs/read_write.c:523:8) osandov#15 __kernel_write (fs/read_write.c:543:9) osandov#16 kernel_write (fs/read_write.c:564:9) osandov#17 kernel_write (fs/read_write.c:554:9) osandov#18 xwrite (init/initramfs.c:33:16) osandov#19 do_copy (init/initramfs.c:405:7) osandov#20 write_buffer (init/initramfs.c:452:10) osandov#21 unpack_to_rootfs (init/initramfs.c:505:14) ... Signed-off-by: Kuan-Ying Lee <[email protected]>
kylee0215
added a commit
to kylee0215/drgn
that referenced
this pull request
Sep 4, 2024
python3 -m drgn -s ./vmlinux -c ./vmcore contrib/page_owner.py --pfn 262144 Sample output: Page last allocated via order 0, gfp_mask: 0x140cca, pid: 74, tgid: 74 (kworker/u32:2), ts 1189257596 ns, free_ts 0 ns PFN: 262203, Flags: 0x3fffe000004003c #0 set_page_owner (./include/linux/page_owner.h:32:3) osandov#1 post_alloc_hook (mm/page_alloc.c:1502:2) osandov#2 prep_new_page (mm/page_alloc.c:1510:2) osandov#3 get_page_from_freelist (mm/page_alloc.c:3489:4) osandov#4 __alloc_pages_noprof (mm/page_alloc.c:4747:9) osandov#5 alloc_pages_mpol_noprof (mm/mempolicy.c:2263:9) osandov#6 folio_alloc_mpol_noprof (mm/mempolicy.c:2281:9) osandov#7 shmem_alloc_folio (mm/shmem.c:1726:10) osandov#8 shmem_alloc_and_add_folio (mm/shmem.c:1786:11) osandov#9 shmem_get_folio_gfp (mm/shmem.c:2192:10) osandov#10 shmem_get_folio (mm/shmem.c:2297:9) osandov#11 shmem_write_begin (mm/shmem.c:2902:8) osandov#12 generic_perform_write (mm/filemap.c:4019:12) osandov#13 shmem_file_write_iter (mm/shmem.c:3078:8) osandov#14 __kernel_write_iter (fs/read_write.c:523:8) osandov#15 __kernel_write (fs/read_write.c:543:9) osandov#16 kernel_write (fs/read_write.c:564:9) osandov#17 kernel_write (fs/read_write.c:554:9) osandov#18 xwrite (init/initramfs.c:33:16) osandov#19 do_copy (init/initramfs.c:405:7) osandov#20 write_buffer (init/initramfs.c:452:10) osandov#21 unpack_to_rootfs (init/initramfs.c:505:14) ... Signed-off-by: Kuan-Ying Lee <[email protected]>
kylee0215
added a commit
to kylee0215/drgn
that referenced
this pull request
Sep 4, 2024
python3 -m drgn -s ./vmlinux -c ./vmcore contrib/page_owner.py --pfn 262144 Sample output: page_owner tracks the page as allocated Page last allocated via order 0, gfp_mask: 0x140cca, pid: 74, tgid: 74 (kworker/u32:2), ts 1187644920 ns, free_ts 0 ns PFN: 262144, Flags: 0x3fffe000004003c #0 set_page_owner (./include/linux/page_owner.h:32:3) osandov#1 post_alloc_hook (mm/page_alloc.c:1502:2) osandov#2 prep_new_page (mm/page_alloc.c:1510:2) osandov#3 get_page_from_freelist (mm/page_alloc.c:3489:4) osandov#4 __alloc_pages_noprof (mm/page_alloc.c:4747:9) osandov#5 alloc_pages_mpol_noprof (mm/mempolicy.c:2263:9) osandov#6 folio_alloc_mpol_noprof (mm/mempolicy.c:2281:9) osandov#7 shmem_alloc_folio (mm/shmem.c:1726:10) osandov#8 shmem_alloc_and_add_folio (mm/shmem.c:1786:11) osandov#9 shmem_get_folio_gfp (mm/shmem.c:2192:10) osandov#10 shmem_get_folio (mm/shmem.c:2297:9) osandov#11 shmem_write_begin (mm/shmem.c:2902:8) osandov#12 generic_perform_write (mm/filemap.c:4019:12) osandov#13 shmem_file_write_iter (mm/shmem.c:3078:8) osandov#14 __kernel_write_iter (fs/read_write.c:523:8) osandov#15 __kernel_write (fs/read_write.c:543:9) osandov#16 kernel_write (fs/read_write.c:564:9) osandov#17 kernel_write (fs/read_write.c:554:9) osandov#18 xwrite (init/initramfs.c:33:16) osandov#19 do_copy (init/initramfs.c:405:7) osandov#20 write_buffer (init/initramfs.c:452:10) osandov#21 unpack_to_rootfs (init/initramfs.c:505:14) page_owner free stack trace missing ... Signed-off-by: Kuan-Ying Lee <[email protected]>
kylee0215
added a commit
to kylee0215/drgn
that referenced
this pull request
Sep 4, 2024
python3 -m drgn -s ./vmlinux -c ./vmcore contrib/page_owner.py --pfn 262144 Sample output: page_owner tracks the page as allocated Page last allocated via order 0, gfp_mask: 0x140cca, pid: 74, tgid: 74 (kworker/u32:2), ts 1187644920 ns, free_ts 0 ns PFN: 262144, Flags: 0x3fffe000004003c #0 set_page_owner (./include/linux/page_owner.h:32:3) osandov#1 post_alloc_hook (mm/page_alloc.c:1502:2) osandov#2 prep_new_page (mm/page_alloc.c:1510:2) osandov#3 get_page_from_freelist (mm/page_alloc.c:3489:4) osandov#4 __alloc_pages_noprof (mm/page_alloc.c:4747:9) osandov#5 alloc_pages_mpol_noprof (mm/mempolicy.c:2263:9) osandov#6 folio_alloc_mpol_noprof (mm/mempolicy.c:2281:9) osandov#7 shmem_alloc_folio (mm/shmem.c:1726:10) osandov#8 shmem_alloc_and_add_folio (mm/shmem.c:1786:11) osandov#9 shmem_get_folio_gfp (mm/shmem.c:2192:10) osandov#10 shmem_get_folio (mm/shmem.c:2297:9) osandov#11 shmem_write_begin (mm/shmem.c:2902:8) osandov#12 generic_perform_write (mm/filemap.c:4019:12) osandov#13 shmem_file_write_iter (mm/shmem.c:3078:8) osandov#14 __kernel_write_iter (fs/read_write.c:523:8) osandov#15 __kernel_write (fs/read_write.c:543:9) osandov#16 kernel_write (fs/read_write.c:564:9) osandov#17 kernel_write (fs/read_write.c:554:9) osandov#18 xwrite (init/initramfs.c:33:16) osandov#19 do_copy (init/initramfs.c:405:7) osandov#20 write_buffer (init/initramfs.c:452:10) osandov#21 unpack_to_rootfs (init/initramfs.c:505:14) page_owner free stack trace missing ... Signed-off-by: Kuan-Ying Lee <[email protected]>
daniel-thompson
added a commit
to daniel-thompson/drgn
that referenced
this pull request
Oct 14, 2024
Both usage and limitations are described in docs/advanced_usage.rst. Testing is been modest but does follow pretty much all the new code paths: 1. the reported register values were compared between gdb and drgn 2. frame pointer based (fallback) stack tracing 3. x0 (argc) and x1 (argv) were checked and the pointers chased to verify that argv[0] contains the right value The autotests are based on osandov#1 and osandov#2 above (there are enough memory reads during a stack trace to exercise the memory read paths). Signed-off-by: Daniel Thompson <[email protected]>
daniel-thompson
added a commit
to daniel-thompson/drgn
that referenced
this pull request
Oct 14, 2024
Both usage and limitations are described in docs/advanced_usage.rst. Testing is been modest but does follow pretty much all the new code paths: 1. the reported register values were compared between gdb and drgn 2. frame pointer based (fallback) stack tracing 3. x0 (argc) and x1 (argv) were checked and the pointers chased to verify that argv[0] contains the right value The autotests are based on osandov#1 and osandov#2 above (there are enough memory reads during a stack trace to exercise the memory read paths). Signed-off-by: Daniel Thompson <[email protected]>
kylee0215
added a commit
to kylee0215/drgn
that referenced
this pull request
Oct 29, 2024
python3 -m drgn -s ./vmlinux -c ./vmcore contrib/page_owner.py --pfn 262144 Sample output: page_owner tracks the page as allocated Page last allocated via order 0, gfp_mask: 0x140cca, pid: 74, tgid: 74 (kworker/u32:2), ts 1187644920 ns, free_ts 0 ns PFN: 262144, Flags: 0x3fffe000004003c #0 set_page_owner (./include/linux/page_owner.h:32:3) osandov#1 post_alloc_hook (mm/page_alloc.c:1502:2) osandov#2 prep_new_page (mm/page_alloc.c:1510:2) osandov#3 get_page_from_freelist (mm/page_alloc.c:3489:4) osandov#4 __alloc_pages_noprof (mm/page_alloc.c:4747:9) osandov#5 alloc_pages_mpol_noprof (mm/mempolicy.c:2263:9) osandov#6 folio_alloc_mpol_noprof (mm/mempolicy.c:2281:9) osandov#7 shmem_alloc_folio (mm/shmem.c:1726:10) osandov#8 shmem_alloc_and_add_folio (mm/shmem.c:1786:11) osandov#9 shmem_get_folio_gfp (mm/shmem.c:2192:10) osandov#10 shmem_get_folio (mm/shmem.c:2297:9) osandov#11 shmem_write_begin (mm/shmem.c:2902:8) osandov#12 generic_perform_write (mm/filemap.c:4019:12) osandov#13 shmem_file_write_iter (mm/shmem.c:3078:8) osandov#14 __kernel_write_iter (fs/read_write.c:523:8) osandov#15 __kernel_write (fs/read_write.c:543:9) osandov#16 kernel_write (fs/read_write.c:564:9) osandov#17 kernel_write (fs/read_write.c:554:9) osandov#18 xwrite (init/initramfs.c:33:16) osandov#19 do_copy (init/initramfs.c:405:7) osandov#20 write_buffer (init/initramfs.c:452:10) osandov#21 unpack_to_rootfs (init/initramfs.c:505:14) page_owner free stack trace missing ... Signed-off-by: Kuan-Ying Lee <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
for_each_cpu is using old attributes "sizeof" and "size". Fix them to
use new ones.
Before patch:
After patch: