Skip to content

Commit 1d50e5d

Browse files
Bhupesh Sharmactmarinas
authored andcommitted
crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo
Right now user-space tools like 'makedumpfile' and 'crash' need to rely on a best-guess method of determining value of 'MAX_PHYSMEM_BITS' supported by underlying kernel. This value is used in user-space code to calculate the bit-space required to store a section for SPARESMEM (similar to the existing calculation method used in the kernel implementation): #define SECTIONS_SHIFT (MAX_PHYSMEM_BITS - SECTION_SIZE_BITS) Now, regressions have been reported in user-space utilities like 'makedumpfile' and 'crash' on arm64, with the recently added kernel support for 52-bit physical address space, as there is no clear method of determining this value in user-space (other than reading kernel CONFIG flags). As per suggestion from makedumpfile maintainer (Kazu), it makes more sense to append 'MAX_PHYSMEM_BITS' to vmcoreinfo in the core code itself rather than in arch-specific code, so that the user-space code for other archs can also benefit from this addition to the vmcoreinfo and use it as a standard way of determining 'SECTIONS_SHIFT' value in user-land. A reference 'makedumpfile' implementation which reads the 'MAX_PHYSMEM_BITS' value from vmcoreinfo in a arch-independent fashion is available here: While at it also update vmcoreinfo documentation for 'MAX_PHYSMEM_BITS' variable being added to vmcoreinfo. 'MAX_PHYSMEM_BITS' defines the maximum supported physical address space memory. Signed-off-by: Bhupesh Sharma <[email protected]> Tested-by: John Donnelly <[email protected]> Acked-by: Dave Young <[email protected]> Cc: Boris Petkov <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: James Morse <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Will Deacon <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Dave Anderson <[email protected]> Cc: Kazuhito Hagio <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
1 parent 9ebcfad commit 1d50e5d

File tree

2 files changed

+6
-0
lines changed

2 files changed

+6
-0
lines changed

Documentation/admin-guide/kdump/vmcoreinfo.rst

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -93,6 +93,11 @@ It exists in the sparse memory mapping model, and it is also somewhat
9393
similar to the mem_map variable, both of them are used to translate an
9494
address.
9595

96+
MAX_PHYSMEM_BITS
97+
----------------
98+
99+
Defines the maximum supported physical address space memory.
100+
96101
page
97102
----
98103

kernel/crash_core.c

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -413,6 +413,7 @@ static int __init crash_save_vmcoreinfo_init(void)
413413
VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
414414
VMCOREINFO_STRUCT_SIZE(mem_section);
415415
VMCOREINFO_OFFSET(mem_section, section_mem_map);
416+
VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
416417
#endif
417418
VMCOREINFO_STRUCT_SIZE(page);
418419
VMCOREINFO_STRUCT_SIZE(pglist_data);

0 commit comments

Comments
 (0)