Hi Dave,
On 24/08/26 12:33 pm, Dave Young wrote:
crash failed with mainline kernel with kaslr enabled.
What does "failed" mean here? A backtrace? Wrong symbols? Please include
the actual error output so the commit log is useful as a bisect landing
point.
Add the flags which will enable kaslr offset calculating.
Signed-off-by: Dave Young <yangrr.2009(a)tsinghua.org.cn>
---
loongarch64.c | 8 ++++++++
1 file changed, 8 insertions(+)
Index: crash/loongarch64.c
===================================================================
--- crash.orig/loongarch64.c 2026-08-18 08:59:46.731117021 +0800
+++ crash/loongarch64.c 2026-08-24 14:55:57.330529708 +0800
@@ -1891,6 +1891,14 @@
machdep->last_ptbl_read = 0;
machdep->verify_paddr = generic_verify_paddr;
machdep->ptrs_per_pgd = PTRS_PER_PGD;
+
+ /*
+ * Even if CONFIG_RANDOMIZE_BASE is not configured,
+ * derive_kaslr_offset() should work and set
+ * kt->relocate to 0
+ */
This comment is same as arm64.c and riscv64.c. On arm64 the comment
justifies why the block runs even when there is no kimage_voffset
condition — here there is no such condition to begin with, so the
"Even if" framing is slightly misleading. Consider rewording to
something like:
/*
* derive_kaslr_offset() handles the CONFIG_RANDOMIZE_BASE=n
* case by setting kt->relocate to 0.
*/
+ if (!kt->relocate && !(kt->flags2 &
(RELOC_AUTO|KASLR)))
+ kt->flags2 |= (RELOC_AUTO|KASLR);
break;
One question, arm64 adjusts kimage_voffset post-relocation and riscv64
adjusts kernel_link_addr, once the KASLR offset is derived. Does
LoongArch need a similar fixup for its virtual-to-physical translation,
or is the global kt->relocate sufficient?
case PRE_GDB:
--
Crash-utility mailing list -- devel(a)lists.crash-utility.osci.io
To unsubscribe send an email to devel-leave(a)lists.crash-utility.osci.io
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines:
https://github.com/crash-utility/crash/wiki
--
Regards,
Mukesh Pilaniya