Hi Kazu, On Tue, Feb 25, 2025 at 2:49 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx> wrote: > > Hi Tao, Lianbo, > > Thank you for the fixes. > > I also hit the issue [3] and not sure how it can be fixed, sharing a bit of information. > It looks like the xen_elfnote_phys32_entry_value is not offset with KASLR offset and > not sorted too. Thanks for sharing your findings. Agreed, the symbol is not kaslr adjusted, the reason should be found out. I will look into it and re-fix it. Thanks, Tao Liu > > crash> sym -l > ... > ffffffff9b030000 (B) _end > ffffffff9b200000 (d) .init.scratch > ffffffff9b200000 (D) __init_scratch_begin > ffffffff9b200000 (d) sme_workarea > ffffffff9b600000 (D) __init_scratch_end > ffffffff846d4fbc (A) xen_elfnote_phys32_entry_value <<--- > ffffffffc038d000 MODULE TEXT START: dm_mod > ffffffffc038d000 (T) __pfx_dm_send_uevents > ffffffffc038d010 (T) dm_send_uevents > ffffffffc038d1a0 (T) __pfx_dm_path_uevent > > $ readelf -s vmlinux | grep xen_elfnote > 213406: ffffffff827d004c 0 NOTYPE GLOBAL DEFAULT 15 xen_elfnote_phys32_entry > 221196: ffffffff846d4fbc 0 NOTYPE GLOBAL DEFAULT ABS xen_elfnote_phys32_entry_ > ^^^^^^^^^^^^^^^^ > > so when the KASLR offset is large enough, all of kernel symbols are considered as > out of kernel symbol range. > > crash> sym schedule > ffffffff992f6c00 (T) schedule /home/kernel/linux-6.14-rc1-localmod/kernel/sched/core.c: 6847 > crash> sym ffffffff992f6c00 > sym: invalid address: ffffffff992f6c00 > > I'm not sure whether it should be re-sorted.. because if we resort it, > the symbol can become lower than _stext, is it ok? > > btw, what is the symbol? why isn't it offset? > > Thanks, > Kazu > > On 2025/02/25 6:19, Tao Liu wrote: > > 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 -- 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
