On Tue, Feb 25, 2025 at 9:49 AM 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.
Thank you for sharing this, Kazu.
I have been curious why I did not reproduce the current issue, this answered my question. It really helps.
Thanks
Lianbo
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
