* Decoding Stack from kernel OOPS message
@ 2018-02-13 9:40 Matwey V. Kornilov
2018-02-13 10:03 ` Denis Kirjanov
0 siblings, 1 reply; 4+ messages in thread
From: Matwey V. Kornilov @ 2018-02-13 9:40 UTC (permalink / raw)
To: kernelnewbies
Hi all,
I have to following message in the logs. What I know is how to convert
'Code' section to assembler or how to convert function/offset to source
code line. Now I wonder how to use stack and register dumps. Given I
have all debugging symbols for binary, it should be possible to map
function local variables to stack and registers (for this particular
stack-trace). Unfortunately, I have not found convenient way how to do
it using gdb.
[ 1733s] [ 1712.306911] Unable to handle kernel paging request at
virtual address 00ad7000
[ 1733s] [ 1712.322041] pgd = e7823740
[ 1733s] [ 1712.322043] [00ad7000] *pgd=67cc1003, *pmd=00000000
[ 1733s] [ 1712.322052] Internal error: Oops: a06 [#1] PREEMPT SMP ARM
[ 1733s] [ 1712.334631] Modules linked in: nls_iso8859_1 nls_cp437 vfat
fat virtio_rng virtio_blk virtio_mmio nf_conntrack_ipv6 nf_defrag_ipv6
nf_conntrack xfs libcrc32c crc32_arm_ce btrfs xor xor_neon zlib_deflate
raid6_pq reiserfs squashfs fuse dm_snapshot dm_bufio dm_mod dax
binfmt_misc loop sg
[ 1733s] [ 1712.334698] CPU: 2 PID: 32027 Comm: rpm Not tainted
4.12.14-lp150.4-lpae #1
[ 1733s] [ 1712.334700] Hardware name: Generic DT based system
[ 1733s] [ 1712.334702] task: eab30000 task.stack: e837c000
[ 1733s] [ 1712.334712] PC is at memcpy+0x50/0x330
[ 1733s] [ 1712.334715] LR is at 0x7020000
[ 1733s] [ 1712.334718] pc : [<c0822b30>] lr : [<07020000>] psr:
20030013
[ 1733s] [ 1712.334718] sp : e837dd8c ip : 1f020000 fp : e837ddd4
[ 1733s] [ 1712.334720] r10: 00ad64e4 r9 : ffedeb1c r8 : 33020000
[ 1733s] [ 1712.334721] r7 : 38020000 r6 : 18020000 r5 : 45020000 r4
: 36020000
[ 1733s] [ 1712.334723] r3 : 1d020000 r2 : 00000444 r1 : ffedeb3c r0
: 00ad7000
[ 1733s] [ 1712.334726] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA
ARM Segment user
[ 1733s] [ 1712.334729] Control: 30c5383d Table: 67823740 DAC: dbadc0de
[ 1733s] [ 1712.334731] Process rpm (pid: 32027, stack limit = 0xe837c210)
[ 1733s] [ 1712.334733] Stack: (0xe837dd8c to 0xe837e000)
[ 1733s] [ 1712.334737] dd80: 00000001
000004e4 00000000 ffffe000 00ad7000
[ 1733s] [ 1712.334741] dda0: 00ad7000 c0833968 e83f46b8 eb4a1e6c
00001000 e837def8 00001000 e837def0
[ 1733s] [ 1712.334744] ddc0: 00000000 ffede000 e837dde4 e837ddd8
c0833b60 c0833890 e837de24 e837dde8
[ 1733s] [ 1712.334747] dde0: c083c4c0 c0833b4c e837de24 e837ddf8
ffede000 efa4cd18 e837de14 e8ebf7f4
[ 1733s] [ 1712.334750] de00: ea070540 efa4cd18 00000614 e8ebf700
e837def8 00001000 e837de94 e837de28
[ 1733s] [ 1712.334753] de20: c05b6620 c083c334 ea028200 b689c000
014000c0 00080001 e837df18 00000000
[ 1733s] [ 1712.334755] de40: 00000613 00000000 00000615 ea0705a8
00a16fff 00000000 00000000 00000000
[ 1733s] [ 1712.334758] de60: ffffe000 00000000 ea028204 00000000
00001000 e837def8 ea070540 e837df80
[ 1733s] [ 1712.334762] de80: 00000000 e837df10 e837ded4 e837de98
c05b6d58 c05b640c c10a764c ea070548
[ 1733s] [ 1712.334765] dea0: 00020000 00000000 00020000 00000000
ea070540 e837df80 00ad64e4 e837df80
[ 1733s] [ 1712.334768] dec0: 00000000 00000000 e837dee4 e837ded8
c06dd35c c05b6c34 e837df4c e837dee8
[ 1733s] [ 1712.334771] dee0: c063c458 c06dd324 00001000 c0686f78
00ad64e4 00001000 00000000 00000000
[ 1733s] [ 1712.334774] df00: 00001000 e837def0 00000001 e837df18
ea070540 00000000 00614000 00000000
[ 1733s] [ 1712.334777] df20: 00000000 00000000 00000000 00000000
ffffe000 00001000 ea070540 00ad64e4
[ 1733s] [ 1712.334780] df40: e837df7c e837df50 c063db2c c063c380
00000000 00000000 ea070540 ea070540
[ 1733s] [ 1712.334783] df60: 00ad64e4 00001000 c04360e8 e837c000
e837dfa4 e837df80 c063f000 c063da9c
[ 1733s] [ 1712.334786] df80: 00614000 00000000 00614000 00000000
00000001 000000b4 00000000 e837dfa8
[ 1733s] [ 1712.334789] dfa0: c0435f20 c063ef88 00614000 00000000
00000003 00ad64e4 00001000 00000000
[ 1733s] [ 1712.334792] dfc0: 00614000 00000000 00000001 000000b4
00000614 00001000 00614000 b6f26d78
[ 1733s] [ 1712.334795] dfe0: b6f2522c be9be5f8 b6edaed8 b6ccdbe8
60030010 00000003 00000000 00000000
[ 1733s] [ 1712.334808] [<c0822b30>] (memcpy) from [<c0833968>]
(__copy_to_user_memcpy+0xe4/0x18c)
[ 1733s] [ 1712.334814] [<c0833968>] (__copy_to_user_memcpy) from
[<c0833b60>] (arm_copy_to_user+0x20/0x34)
[ 1733s] [ 1712.334819] [<c0833b60>] (arm_copy_to_user) from
[<c083c4c0>] (copy_page_to_iter+0x198/0x414)
[ 1733s] [ 1712.334826] [<c083c4c0>] (copy_page_to_iter) from
[<c05b6620>] (do_generic_file_read+0x220/0x828)
[ 1733s] [ 1712.334834] [<c05b6620>] (do_generic_file_read) from
[<c05b6d58>] (generic_file_read_iter+0x130/0x184)
[ 1733s] [ 1712.334840] [<c05b6d58>] (generic_file_read_iter) from
[<c06dd35c>] (ext4_file_read_iter+0x44/0x58)
[ 1733s] [ 1712.334849] [<c06dd35c>] (ext4_file_read_iter) from
[<c063c458>] (__vfs_read+0xe4/0x130)
[ 1733s] [ 1712.334855] [<c063c458>] (__vfs_read) from [<c063db2c>]
(vfs_read+0x9c/0x164)
[ 1733s] [ 1712.334860] [<c063db2c>] (vfs_read) from [<c063f000>]
(SyS_pread64+0x84/0x9c)
[ 1733s] [ 1712.334867] [<c063f000>] (SyS_pread64) from [<c0435f20>]
(ret_fast_syscall+0x0/0x34)
[ 1733s] [ 1712.334872] Code: f5d1f05c f5d1f07c e8b151f8 e2522020
(e8a051f8)
[ 1733s] [ 1712.334906] ---[ end trace 9514fd2a41e5765d ]---
^ permalink raw reply [flat|nested] 4+ messages in thread
* Decoding Stack from kernel OOPS message
2018-02-13 9:40 Decoding Stack from kernel OOPS message Matwey V. Kornilov
@ 2018-02-13 10:03 ` Denis Kirjanov
2018-02-13 11:47 ` Matwey V. Kornilov
0 siblings, 1 reply; 4+ messages in thread
From: Denis Kirjanov @ 2018-02-13 10:03 UTC (permalink / raw)
To: kernelnewbies
On 2/13/18, Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote:
> Hi all,
>
> I have to following message in the logs. What I know is how to convert
> 'Code' section to assembler or how to convert function/offset to source
> code line. Now I wonder how to use stack and register dumps. Given I
> have all debugging symbols for binary, it should be possible to map
> function local variables to stack and registers (for this particular
> stack-trace). Unfortunately, I have not found convenient way how to do
> it using gdb.
>
Nope, you can do that by disassembling the caller functions and checking how
parameters are passed (regs or stack).
It's easier to setup a kdump on a mchine and use crash utility for that.
> [ 1733s] [ 1712.306911] Unable to handle kernel paging request at
> virtual address 00ad7000
> [ 1733s] [ 1712.322041] pgd = e7823740
> [ 1733s] [ 1712.322043] [00ad7000] *pgd=67cc1003, *pmd=00000000
> [ 1733s] [ 1712.322052] Internal error: Oops: a06 [#1] PREEMPT SMP ARM
> [ 1733s] [ 1712.334631] Modules linked in: nls_iso8859_1 nls_cp437 vfat
> fat virtio_rng virtio_blk virtio_mmio nf_conntrack_ipv6 nf_defrag_ipv6
> nf_conntrack xfs libcrc32c crc32_arm_ce btrfs xor xor_neon zlib_deflate
> raid6_pq reiserfs squashfs fuse dm_snapshot dm_bufio dm_mod dax
> binfmt_misc loop sg
> [ 1733s] [ 1712.334698] CPU: 2 PID: 32027 Comm: rpm Not tainted
> 4.12.14-lp150.4-lpae #1
> [ 1733s] [ 1712.334700] Hardware name: Generic DT based system
> [ 1733s] [ 1712.334702] task: eab30000 task.stack: e837c000
> [ 1733s] [ 1712.334712] PC is at memcpy+0x50/0x330
> [ 1733s] [ 1712.334715] LR is at 0x7020000
> [ 1733s] [ 1712.334718] pc : [<c0822b30>] lr : [<07020000>] psr:
> 20030013
> [ 1733s] [ 1712.334718] sp : e837dd8c ip : 1f020000 fp : e837ddd4
> [ 1733s] [ 1712.334720] r10: 00ad64e4 r9 : ffedeb1c r8 : 33020000
> [ 1733s] [ 1712.334721] r7 : 38020000 r6 : 18020000 r5 : 45020000 r4
> : 36020000
> [ 1733s] [ 1712.334723] r3 : 1d020000 r2 : 00000444 r1 : ffedeb3c r0
> : 00ad7000
> [ 1733s] [ 1712.334726] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA
> ARM Segment user
> [ 1733s] [ 1712.334729] Control: 30c5383d Table: 67823740 DAC: dbadc0de
> [ 1733s] [ 1712.334731] Process rpm (pid: 32027, stack limit = 0xe837c210)
> [ 1733s] [ 1712.334733] Stack: (0xe837dd8c to 0xe837e000)
> [ 1733s] [ 1712.334737] dd80: 00000001
> 000004e4 00000000 ffffe000 00ad7000
> [ 1733s] [ 1712.334741] dda0: 00ad7000 c0833968 e83f46b8 eb4a1e6c
> 00001000 e837def8 00001000 e837def0
> [ 1733s] [ 1712.334744] ddc0: 00000000 ffede000 e837dde4 e837ddd8
> c0833b60 c0833890 e837de24 e837dde8
> [ 1733s] [ 1712.334747] dde0: c083c4c0 c0833b4c e837de24 e837ddf8
> ffede000 efa4cd18 e837de14 e8ebf7f4
> [ 1733s] [ 1712.334750] de00: ea070540 efa4cd18 00000614 e8ebf700
> e837def8 00001000 e837de94 e837de28
> [ 1733s] [ 1712.334753] de20: c05b6620 c083c334 ea028200 b689c000
> 014000c0 00080001 e837df18 00000000
> [ 1733s] [ 1712.334755] de40: 00000613 00000000 00000615 ea0705a8
> 00a16fff 00000000 00000000 00000000
> [ 1733s] [ 1712.334758] de60: ffffe000 00000000 ea028204 00000000
> 00001000 e837def8 ea070540 e837df80
> [ 1733s] [ 1712.334762] de80: 00000000 e837df10 e837ded4 e837de98
> c05b6d58 c05b640c c10a764c ea070548
> [ 1733s] [ 1712.334765] dea0: 00020000 00000000 00020000 00000000
> ea070540 e837df80 00ad64e4 e837df80
> [ 1733s] [ 1712.334768] dec0: 00000000 00000000 e837dee4 e837ded8
> c06dd35c c05b6c34 e837df4c e837dee8
> [ 1733s] [ 1712.334771] dee0: c063c458 c06dd324 00001000 c0686f78
> 00ad64e4 00001000 00000000 00000000
> [ 1733s] [ 1712.334774] df00: 00001000 e837def0 00000001 e837df18
> ea070540 00000000 00614000 00000000
> [ 1733s] [ 1712.334777] df20: 00000000 00000000 00000000 00000000
> ffffe000 00001000 ea070540 00ad64e4
> [ 1733s] [ 1712.334780] df40: e837df7c e837df50 c063db2c c063c380
> 00000000 00000000 ea070540 ea070540
> [ 1733s] [ 1712.334783] df60: 00ad64e4 00001000 c04360e8 e837c000
> e837dfa4 e837df80 c063f000 c063da9c
> [ 1733s] [ 1712.334786] df80: 00614000 00000000 00614000 00000000
> 00000001 000000b4 00000000 e837dfa8
> [ 1733s] [ 1712.334789] dfa0: c0435f20 c063ef88 00614000 00000000
> 00000003 00ad64e4 00001000 00000000
> [ 1733s] [ 1712.334792] dfc0: 00614000 00000000 00000001 000000b4
> 00000614 00001000 00614000 b6f26d78
> [ 1733s] [ 1712.334795] dfe0: b6f2522c be9be5f8 b6edaed8 b6ccdbe8
> 60030010 00000003 00000000 00000000
> [ 1733s] [ 1712.334808] [<c0822b30>] (memcpy) from [<c0833968>]
> (__copy_to_user_memcpy+0xe4/0x18c)
> [ 1733s] [ 1712.334814] [<c0833968>] (__copy_to_user_memcpy) from
> [<c0833b60>] (arm_copy_to_user+0x20/0x34)
> [ 1733s] [ 1712.334819] [<c0833b60>] (arm_copy_to_user) from
> [<c083c4c0>] (copy_page_to_iter+0x198/0x414)
> [ 1733s] [ 1712.334826] [<c083c4c0>] (copy_page_to_iter) from
> [<c05b6620>] (do_generic_file_read+0x220/0x828)
> [ 1733s] [ 1712.334834] [<c05b6620>] (do_generic_file_read) from
> [<c05b6d58>] (generic_file_read_iter+0x130/0x184)
> [ 1733s] [ 1712.334840] [<c05b6d58>] (generic_file_read_iter) from
> [<c06dd35c>] (ext4_file_read_iter+0x44/0x58)
> [ 1733s] [ 1712.334849] [<c06dd35c>] (ext4_file_read_iter) from
> [<c063c458>] (__vfs_read+0xe4/0x130)
> [ 1733s] [ 1712.334855] [<c063c458>] (__vfs_read) from [<c063db2c>]
> (vfs_read+0x9c/0x164)
> [ 1733s] [ 1712.334860] [<c063db2c>] (vfs_read) from [<c063f000>]
> (SyS_pread64+0x84/0x9c)
> [ 1733s] [ 1712.334867] [<c063f000>] (SyS_pread64) from [<c0435f20>]
> (ret_fast_syscall+0x0/0x34)
> [ 1733s] [ 1712.334872] Code: f5d1f05c f5d1f07c e8b151f8 e2522020
> (e8a051f8)
> [ 1733s] [ 1712.334906] ---[ end trace 9514fd2a41e5765d ]---
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
--
Regards / Mit besten Gr??en,
Denis
^ permalink raw reply [flat|nested] 4+ messages in thread
* Decoding Stack from kernel OOPS message
2018-02-13 10:03 ` Denis Kirjanov
@ 2018-02-13 11:47 ` Matwey V. Kornilov
2018-02-13 15:49 ` valdis.kletnieks at vt.edu
0 siblings, 1 reply; 4+ messages in thread
From: Matwey V. Kornilov @ 2018-02-13 11:47 UTC (permalink / raw)
To: kernelnewbies
2018-02-13 13:03 GMT+03:00 Denis Kirjanov <kirjanov@gmail.com>:
> On 2/13/18, Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote:
>> Hi all,
>>
>> I have to following message in the logs. What I know is how to convert
>> 'Code' section to assembler or how to convert function/offset to source
>> code line. Now I wonder how to use stack and register dumps. Given I
>> have all debugging symbols for binary, it should be possible to map
>> function local variables to stack and registers (for this particular
>> stack-trace). Unfortunately, I have not found convenient way how to do
>> it using gdb.
>>
>
> Nope, you can do that by disassembling the caller functions and checking how
> parameters are passed (regs or stack).
Well, It is not clear to me. First, what is the purpose to dump the
stack? Second, when I use gdb with ordinary user-space applications,
then for every execution step I can do commands to print variables or
expressions. It is obvious that gdb has mapping between variables in
the source code and memory/register locations for any specific step.
Isn't this mapping derivable from debug info?
>
> It's easier to setup a kdump on a mchine and use crash utility for that.
>
>> [ 1733s] [ 1712.306911] Unable to handle kernel paging request at
>> virtual address 00ad7000
>> [ 1733s] [ 1712.322041] pgd = e7823740
>> [ 1733s] [ 1712.322043] [00ad7000] *pgd=67cc1003, *pmd=00000000
>> [ 1733s] [ 1712.322052] Internal error: Oops: a06 [#1] PREEMPT SMP ARM
>> [ 1733s] [ 1712.334631] Modules linked in: nls_iso8859_1 nls_cp437 vfat
>> fat virtio_rng virtio_blk virtio_mmio nf_conntrack_ipv6 nf_defrag_ipv6
>> nf_conntrack xfs libcrc32c crc32_arm_ce btrfs xor xor_neon zlib_deflate
>> raid6_pq reiserfs squashfs fuse dm_snapshot dm_bufio dm_mod dax
>> binfmt_misc loop sg
>> [ 1733s] [ 1712.334698] CPU: 2 PID: 32027 Comm: rpm Not tainted
>> 4.12.14-lp150.4-lpae #1
>> [ 1733s] [ 1712.334700] Hardware name: Generic DT based system
>> [ 1733s] [ 1712.334702] task: eab30000 task.stack: e837c000
>> [ 1733s] [ 1712.334712] PC is at memcpy+0x50/0x330
>> [ 1733s] [ 1712.334715] LR is at 0x7020000
>> [ 1733s] [ 1712.334718] pc : [<c0822b30>] lr : [<07020000>] psr:
>> 20030013
>> [ 1733s] [ 1712.334718] sp : e837dd8c ip : 1f020000 fp : e837ddd4
>> [ 1733s] [ 1712.334720] r10: 00ad64e4 r9 : ffedeb1c r8 : 33020000
>> [ 1733s] [ 1712.334721] r7 : 38020000 r6 : 18020000 r5 : 45020000 r4
>> : 36020000
>> [ 1733s] [ 1712.334723] r3 : 1d020000 r2 : 00000444 r1 : ffedeb3c r0
>> : 00ad7000
>> [ 1733s] [ 1712.334726] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA
>> ARM Segment user
>> [ 1733s] [ 1712.334729] Control: 30c5383d Table: 67823740 DAC: dbadc0de
>> [ 1733s] [ 1712.334731] Process rpm (pid: 32027, stack limit = 0xe837c210)
>> [ 1733s] [ 1712.334733] Stack: (0xe837dd8c to 0xe837e000)
>> [ 1733s] [ 1712.334737] dd80: 00000001
>> 000004e4 00000000 ffffe000 00ad7000
>> [ 1733s] [ 1712.334741] dda0: 00ad7000 c0833968 e83f46b8 eb4a1e6c
>> 00001000 e837def8 00001000 e837def0
>> [ 1733s] [ 1712.334744] ddc0: 00000000 ffede000 e837dde4 e837ddd8
>> c0833b60 c0833890 e837de24 e837dde8
>> [ 1733s] [ 1712.334747] dde0: c083c4c0 c0833b4c e837de24 e837ddf8
>> ffede000 efa4cd18 e837de14 e8ebf7f4
>> [ 1733s] [ 1712.334750] de00: ea070540 efa4cd18 00000614 e8ebf700
>> e837def8 00001000 e837de94 e837de28
>> [ 1733s] [ 1712.334753] de20: c05b6620 c083c334 ea028200 b689c000
>> 014000c0 00080001 e837df18 00000000
>> [ 1733s] [ 1712.334755] de40: 00000613 00000000 00000615 ea0705a8
>> 00a16fff 00000000 00000000 00000000
>> [ 1733s] [ 1712.334758] de60: ffffe000 00000000 ea028204 00000000
>> 00001000 e837def8 ea070540 e837df80
>> [ 1733s] [ 1712.334762] de80: 00000000 e837df10 e837ded4 e837de98
>> c05b6d58 c05b640c c10a764c ea070548
>> [ 1733s] [ 1712.334765] dea0: 00020000 00000000 00020000 00000000
>> ea070540 e837df80 00ad64e4 e837df80
>> [ 1733s] [ 1712.334768] dec0: 00000000 00000000 e837dee4 e837ded8
>> c06dd35c c05b6c34 e837df4c e837dee8
>> [ 1733s] [ 1712.334771] dee0: c063c458 c06dd324 00001000 c0686f78
>> 00ad64e4 00001000 00000000 00000000
>> [ 1733s] [ 1712.334774] df00: 00001000 e837def0 00000001 e837df18
>> ea070540 00000000 00614000 00000000
>> [ 1733s] [ 1712.334777] df20: 00000000 00000000 00000000 00000000
>> ffffe000 00001000 ea070540 00ad64e4
>> [ 1733s] [ 1712.334780] df40: e837df7c e837df50 c063db2c c063c380
>> 00000000 00000000 ea070540 ea070540
>> [ 1733s] [ 1712.334783] df60: 00ad64e4 00001000 c04360e8 e837c000
>> e837dfa4 e837df80 c063f000 c063da9c
>> [ 1733s] [ 1712.334786] df80: 00614000 00000000 00614000 00000000
>> 00000001 000000b4 00000000 e837dfa8
>> [ 1733s] [ 1712.334789] dfa0: c0435f20 c063ef88 00614000 00000000
>> 00000003 00ad64e4 00001000 00000000
>> [ 1733s] [ 1712.334792] dfc0: 00614000 00000000 00000001 000000b4
>> 00000614 00001000 00614000 b6f26d78
>> [ 1733s] [ 1712.334795] dfe0: b6f2522c be9be5f8 b6edaed8 b6ccdbe8
>> 60030010 00000003 00000000 00000000
>> [ 1733s] [ 1712.334808] [<c0822b30>] (memcpy) from [<c0833968>]
>> (__copy_to_user_memcpy+0xe4/0x18c)
>> [ 1733s] [ 1712.334814] [<c0833968>] (__copy_to_user_memcpy) from
>> [<c0833b60>] (arm_copy_to_user+0x20/0x34)
>> [ 1733s] [ 1712.334819] [<c0833b60>] (arm_copy_to_user) from
>> [<c083c4c0>] (copy_page_to_iter+0x198/0x414)
>> [ 1733s] [ 1712.334826] [<c083c4c0>] (copy_page_to_iter) from
>> [<c05b6620>] (do_generic_file_read+0x220/0x828)
>> [ 1733s] [ 1712.334834] [<c05b6620>] (do_generic_file_read) from
>> [<c05b6d58>] (generic_file_read_iter+0x130/0x184)
>> [ 1733s] [ 1712.334840] [<c05b6d58>] (generic_file_read_iter) from
>> [<c06dd35c>] (ext4_file_read_iter+0x44/0x58)
>> [ 1733s] [ 1712.334849] [<c06dd35c>] (ext4_file_read_iter) from
>> [<c063c458>] (__vfs_read+0xe4/0x130)
>> [ 1733s] [ 1712.334855] [<c063c458>] (__vfs_read) from [<c063db2c>]
>> (vfs_read+0x9c/0x164)
>> [ 1733s] [ 1712.334860] [<c063db2c>] (vfs_read) from [<c063f000>]
>> (SyS_pread64+0x84/0x9c)
>> [ 1733s] [ 1712.334867] [<c063f000>] (SyS_pread64) from [<c0435f20>]
>> (ret_fast_syscall+0x0/0x34)
>> [ 1733s] [ 1712.334872] Code: f5d1f05c f5d1f07c e8b151f8 e2522020
>> (e8a051f8)
>> [ 1733s] [ 1712.334906] ---[ end trace 9514fd2a41e5765d ]---
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>
> --
> Regards / Mit besten Gr??en,
> Denis
--
With best regards,
Matwey V. Kornilov
^ permalink raw reply [flat|nested] 4+ messages in thread
* Decoding Stack from kernel OOPS message
2018-02-13 11:47 ` Matwey V. Kornilov
@ 2018-02-13 15:49 ` valdis.kletnieks at vt.edu
0 siblings, 0 replies; 4+ messages in thread
From: valdis.kletnieks at vt.edu @ 2018-02-13 15:49 UTC (permalink / raw)
To: kernelnewbies
On Tue, 13 Feb 2018 14:47:32 +0300, "Matwey V. Kornilov" said:
> Well, It is not clear to me. First, what is the purpose to dump the
> stack? Second, when I use gdb with ordinary user-space applications,
> then for every execution step I can do commands to print variables or
> expressions. It is obvious that gdb has mapping between variables in
> the source code and memory/register locations for any specific step.
> Isn't this mapping derivable from debug info?
There's two places that the info can be found - when the kernel splats
the error message into the dmesg buffer, and in userspace when you're
looking at the wreckage.
Note that the info you're looking at is in a file on disk - and thus off-limits
to the kernel. Doing file I/O inside the kernel is ugly enough, but doing it
while processing an error condition is totally beyond the pale (it's able to
unwind the function names from the stack traceback because *that* info
is already loaded into memory for many configurations of the kernel).
The second time is when you're looking at gdb after the fact - at which point
you need to worry about stuff like KALSR and so on. Also, you're no longer
looking at a live stack in memory, you're looking at the output of a bunch of
printf statements - that adds to the challenge.
Have you looked at using objdump? You'll need to figure out which .o/.ko has
the function in it, but then. (As always figuring out what asm lines up with what
C code is left as an exercise for the programmer, but 90% of the time once you
know what register has the bad value in it, you can work backwards to either
a global variable or a value passed in a function parameter).
[/usr/src/linux-next] objdump -d arch/x86/lib/usercopy_64.o | head -20
arch/x86/lib/usercopy_64.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <__clear_user>:
0: e8 00 00 00 00 callq 5 <__clear_user+0x5>
5: 55 push %rbp
6: 48 89 e5 mov %rsp,%rbp
9: 41 54 push %r12
b: 49 89 fc mov %rdi,%r12
e: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
15: 53 push %rbx
16: 48 89 f3 mov %rsi,%rbx
19: be 13 00 00 00 mov $0x13,%esi
1e: e8 00 00 00 00 callq 23 <__clear_user+0x23>
23: 90 nop
24: 90 nop
25: 90 nop
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180213/8ac3186e/attachment.sig>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-02-13 15:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-02-13 9:40 Decoding Stack from kernel OOPS message Matwey V. Kornilov
2018-02-13 10:03 ` Denis Kirjanov
2018-02-13 11:47 ` Matwey V. Kornilov
2018-02-13 15:49 ` valdis.kletnieks at vt.edu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).