Hi Lianbo,
On Mon, Feb 24, 2025 at 10:03 PM lijiang <[email protected]> wrote:
>
> Thank you for the fix, Tao.
>
> On Mon, Feb 24, 2025 at 11:02 AM <[email protected]>
> wrote:
>>
>> Date: Mon, 24 Feb 2025 15:59:11 +1300
>> From: Tao Liu <[email protected]>
>> Subject: [Crash-utility] [PATCH 0/3] Several fixes for v6.14-rc
>> kernels
>> To: [email protected]
>> Cc: [email protected], Tao Liu <[email protected]>
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>>
>> There are a few failing cases observed on v6.14-rc kernel. This patchset
>> will fix these.
>>
>> For the NO.1 patch, Anderson used "vtop" cmd as the test case [1], which I
>> cannot reproduce because I didn't find a suitable value for vtop to
>> trigger the failing. So I switched to "files" cmd.
>>
>> [1]:
>> https://www.mail-archive.com/[email protected]/msg01356.html
>>
>> Tao Liu (3):
>> Fix the failing of cmd "files" for v6.14-rc1 kernel
>> Fix the failing of cmd "runq -g" for v6.14-rc1 kernel
>
>
> The patch [1] and [2] are fine to me, applied:
> [1]
> https://github.com/crash-utility/crash/commit/2795136a515446b798ebbfa257c97f0ca6ecb8ec
> [2]
> https://github.com/crash-utility/crash/commit/080b4baf5d5e998750f80289c847f162bb81a043
>
Thanks for applying the patches.
>> Sort the symtable at the end of store_symbols()
>>
>
> For the patch [3], I did not reproduce the current issue, can you try to
> provide some unsorted symbols information?
>
Sure, this is the st->symtable at the end of function store_symbols()
without the NO.3 patch:
(gdb) p/x st->symtable[st->symcnt-1]
$13 = {value = 0xffffffff853da7f4, name = 0x1e75ae4, val_hash_next =
0x0, name_hash_next = 0x0, type = 0x41, cnt = 0x0, flags = 0x0,
pad2 = 0x0}
(gdb) x/s st->symtable[st->symcnt-1].name
0x1e75ae4: "xen_elfnote_phys32_entry_value"
(gdb) p/x st->symtable[st->symcnt-2]
$14 = {value = 0xffffffff99a00000, name = 0x1e75ad1, val_hash_next =
0x0, name_hash_next = 0x0, type = 0x44, cnt = 0x0, flags = 0x0,
pad2 = 0x0}
(gdb) x/s st->symtable[st->symcnt-2].name
0x1e75ad1: "__init_scratch_end"
(gdb) p/x st->symtable[st->symcnt-3]
$15 = {value = 0xffffffff99600000, name = 0x1e75ac4, val_hash_next =
0x0, name_hash_next = 0x0, type = 0x64, cnt = 0x0, flags = 0x0,
pad2 = 0x0}
(gdb) x/s st->symtable[st->symcnt-3].name
0x1e75ac4: "sme_workarea"
(gdb) p/x st->symtable[st->symcnt-4]
$16 = {value = 0xffffffff99600000, name = 0x1e75aaf, val_hash_next =
0x0, name_hash_next = 0x0, type = 0x44, cnt = 0x0, flags = 0x0,
pad2 = 0x0}
(gdb) x/s st->symtable[st->symcnt-4].name
0x1e75aaf: "__init_scratch_begin"
The "st->symcnt-1" one is the last element of st->symtable, and should
have the highest value. However it is not.
> Maybe there are similar cases such as store_sysmap_symbols.
I think we don't need a re-sort for store_sysmap_symbols(), because
the symbols read by store_sysmap_symbols() is from System.map file,
which already have the symbols sorted by default.
Thanks,
Tao Liu
>
>
> Thanks
> Lianbo
>
>>
>> filesys.c | 3 +++
>> symbols.c | 3 +++
>> task.c | 3 +++
>> 3 files changed, 9 insertions(+)
>>
>> --
>> 2.47.0
--
Crash-utility mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
