Re: [PATCH 1/1 module-next] kallsyms: enhance %pS/s/b printing when KALLSYSMS is disabled
From: Petr Mladek <pmladek@suse.com>
Date: 2022-03-17 10:59:24
Also in:
lkml
Possibly related (same subject, not in this thread)
- 2022-03-22 · RE: [PATCH 1/1 module-next] kallsyms: enhance %pS/s/b printing when KALLSYSMS is disabled · Maninder Singh <hidden>
On Wed 2022-03-16 10:05:40, Maninder Singh wrote:
quoted hunk ↗ jump to hunk
print module information when KALLSYMS is disabled. No change for %pB, as it needs to know symbol name to adjust address value which can't be done without KALLSYMS. (A) original output with KALLSYMS: [8.842129] ps function_1 [crash] [8.842735] pS function_1+0x4/0x2c [crash] [8.842890] pSb function_1+0x4/0x2c [crash b367e79021b9f3b0172f9a36d4261c1f528ca1b3] [8.843175] pB function_1+0x4/0x2c [crash] [8.843362] pBb function_1+0x4/0x2c [crash b367e79021b9f3b0172f9a36d4261c1f528ca1b3] (B) original output without KALLSYMS: [12.487424] ps 0xffff800000eb008c [12.487598] pS 0xffff800000eb008c [12.487723] pSb 0xffff800000eb008c [12.487850] pB 0xffff800000eb008c [12.487967] pBb 0xffff800000eb008c (C) With patched kernel with KALLYSMS: [41.974576] ps function_1 [crash] [41.975173] pS function_1+0x4/0x2c [crash] [41.975386] pSb function_1+0x4/0x2c [crash a8b20caaec9635b316cf4812f6b55598fe2b7cee] [41.975879] pB function_1+0x4/0x2c [crash] [41.976076] pBb function_1+0x4/0x2c [crash a8b20caaec9635b316cf4812f6b55598fe2b7cee] without KALLSYMS: [9.624152] ps 0xffff800001bd008c [crash] // similar to original, no changes [9.624548] pS 0x(____ptrval____)+0x8c [crash] // base address hashed and offset is without hash [9.624847] pSb 0x(____ptrval____)+0x8c [crash a8b20caaec9635b316cf4812f6b55598fe2b7cee] [9.625388] pB 0x(____ptrval____)+0x8c [crash] [9.625594] pBb 0x(____ptrval____)+0x8c [crash a8b20caaec9635b316cf4812f6b55598fe2b7cee] with disable hashing: [8.563916] ps 0xffff800000f2008c [crash] [8.564574] pS 0xffff800000f20000+0x8c [crash] [8.564749] pSb 0xffff800000f20000+0x8c [crash 3423a8993a7033fb79e5add14bf9d8d6b56330ca] [8.565008] pB 0xffff800000f20000+0x8c [crash] [8.565154] pBb 0xffff800000f20000+0x8c [crash 3423a8993a7033fb79e5add14bf9d8d6b56330ca]--- a/lib/vsprintf.c +++ b/lib/vsprintf.c@@ -979,33 +979,92 @@ char *bdev_name(char *buf, char *end, struct block_device *bdev, } #endif +#if !defined(CONFIG_KALLSYMS) && defined(CONFIG_MODULES) +static int sprint_module_info(char *buf, unsigned long value, + int modbuildid, int backtrace, int symbol) +{ + struct module *mod; + unsigned long offset; + void *base; + char *modname; + int len; + const unsigned char *buildid = NULL; + bool add_offset; + + if (is_ksym_addr(value)) + return 0; + + if (backtrace || symbol) + add_offset = true; + else + add_offset = false; + + preempt_disable(); + mod = __module_address(value); + if (mod) { + modname = mod->name; +#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID) + if (modbuildid) + buildid = mod->build_id; +#endif + if (add_offset) { + base = mod->core_layout.base; + offset = value - (unsigned long)base; + } + } + preempt_enable(); + if (!mod) + return 0;
I think that some earlier version of the patch allowed to print also the address from vmlinux with the offset. My concern was that it would show non-hashed base pointer. IMHO, it is fine to show it hashed.
+ + /* address belongs to module */ + if (add_offset) + len = sprintf(buf, "0x%p+0x%lx", base, offset); + else + len = sprintf(buf, "0x%lx", value); + + return len + fill_name_build_id(buf, modname, modbuildid, buildid, len); +}
Otherwise, it looks good to me. I did also some basic testing. The vmlinux address with offset can be added by a followup patch. Feel free to use: Reviewed-by: Petr Mladek <pmladek@suse.com> Tested-by: Petr Mladek <pmladek@suse.com> Best Regards, Petr