[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1552212242-9479-3-git-send-email-bhsharma@redhat.com>
Date: Sun, 10 Mar 2019 15:34:02 +0530
From: Bhupesh Sharma <bhsharma@...hat.com>
To: linux-kernel@...r.kernel.org
Cc: bhsharma@...hat.com, bhupesh.linux@...il.com,
Boris Petkov <bp@...en8.de>, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
James Morse <james.morse@....com>,
Will Deacon <will.deacon@....com>,
Michael Ellerman <mpe@...erman.id.au>,
Paul Mackerras <paulus@...ba.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Dave Anderson <anderson@...hat.com>,
Kazuhito Hagio <k-hagio@...jp.nec.com>, x86@...nel.org,
linuxppc-dev@...ts.ozlabs.org,
linux-arm-kernel@...ts.infradead.org, kexec@...ts.infradead.org
Subject: [PATCH v2 2/2] 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:
[0]. https://github.com/bhupesh-sharma/makedumpfile/blob/remove-max-phys-mem-bit-v1/arch/ppc64.c#L471
Cc: Boris Petkov <bp@...en8.de>
Cc: Ingo Molnar <mingo@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: James Morse <james.morse@....com>
Cc: Will Deacon <will.deacon@....com>
Cc: Michael Ellerman <mpe@...erman.id.au>
Cc: Paul Mackerras <paulus@...ba.org>
Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Dave Anderson <anderson@...hat.com>
Cc: Kazuhito Hagio <k-hagio@...jp.nec.com>
Cc: x86@...nel.org
Cc: linuxppc-dev@...ts.ozlabs.org
Cc: linux-arm-kernel@...ts.infradead.org
Cc: linux-kernel@...r.kernel.org
Cc: kexec@...ts.infradead.org
Signed-off-by: Bhupesh Sharma <bhsharma@...hat.com>
---
kernel/crash_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 093c9f917ed0..44b90368e183 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -467,6 +467,7 @@ static int __init crash_save_vmcoreinfo_init(void)
#define PAGE_OFFLINE_MAPCOUNT_VALUE (~PG_offline)
VMCOREINFO_NUMBER(PAGE_OFFLINE_MAPCOUNT_VALUE);
#endif
+ VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
arch_crash_save_vmcoreinfo();
update_vmcoreinfo_note();
--
2.7.4
Powered by blists - more mailing lists