mirror of
git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git
synced 2026-10-31 06:14:39 +01:00
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]>
This commit is contained in:
1 parent
9ebcfadb06
commit
1d50e5d0c5
2 files changed
+6
No files matched your search
@@ -93,6 +93,11 @@ It exists in the sparse memory mapping model, and it is also somewhat
|
||||
similar to the mem_map variable, both of them are used to translate an
|
||||
address.
|
||||
|
||||
MAX_PHYSMEM_BITS
|
||||
----------------
|
||||
|
||||
Defines the maximum supported physical address space memory.
|
||||
|
||||
page
|
||||
----
|
||||
|
||||
|
||||
@@ -413,6 +413,7 @@ static int __init crash_save_vmcoreinfo_init(void)
|
||||
VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
|
||||
VMCOREINFO_STRUCT_SIZE(mem_section);
|
||||
VMCOREINFO_OFFSET(mem_section, section_mem_map);
|
||||
VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
|
||||
#endif
|
||||
VMCOREINFO_STRUCT_SIZE(page);
|
||||
VMCOREINFO_STRUCT_SIZE(pglist_data);
|
||||
|
||||
Reference in new issue
Block a user