Hi Lianbo, On Mon, Feb 24, 2025 at 10:03 PM lijiang <lijiang@xxxxxxxxxx> wrote: > > Thank you for the fix, Tao. > > On Mon, Feb 24, 2025 at 11:02 AM <devel-request@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: >> >> Date: Mon, 24 Feb 2025 15:59:11 +1300 >> From: Tao Liu <ltao@xxxxxxxxxx> >> Subject: [PATCH 0/3] Several fixes for v6.14-rc >> kernels >> To: devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx >> Cc: andersonc0d3@xxxxxxxxx, Tao Liu <ltao@xxxxxxxxxx> >> Message-ID: <20250224025914.16044-1-ltao@xxxxxxxxxx> >> 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/devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx/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 -- devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxxxxx https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ Contribution Guidelines: https://github.com/crash-utility/crash/wiki
