Make the default for PHYSICAL_START always 64-bit, ensuring that a correct sign-extended value is used if a 32-bit image is loaded by a 64-bit system, and matching how the load address is set in platform Makefile fragments (arch/mips/*/Platform) in the absence of the PHYSICAL_START configuration option.
Of course PHYSICAL_START itself is a misnomer as the load address is virtual rather than physical (or otherwise sign-extension would not apply).
Signed-off-by: Maciej W. Rozycki macro@mips.com Fixes: 7aa1c8f47e7e ("MIPS: kdump: Add support") Cc: stable@vger.kernel.org # 3.8+ --- Hi James,
As discussed in the context of commit 27c524d17430 ("MIPS: Use the entry point from the ELF file header"). This may require verifying by someone who actually uses this feature. I have cc-ed Maxim, the original author, in case he has anything to add.
I'm not sure if we want to do anything about the physical vs virtual load address confusion.
Please consider.
Maciej --- arch/mips/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
linux-mips-physical-start.diff Index: linux-jhogan-test/arch/mips/Kconfig =================================================================== --- linux-jhogan-test.orig/arch/mips/Kconfig 2018-03-21 17:22:12.000000000 +0000 +++ linux-jhogan-test/arch/mips/Kconfig 2018-03-23 09:19:25.049100000 +0000 @@ -2849,8 +2849,7 @@ config CRASH_DUMP
config PHYSICAL_START hex "Physical address where the kernel is loaded" - default "0xffffffff84000000" if 64BIT - default "0x84000000" if 32BIT + default "0xffffffff84000000" depends on CRASH_DUMP help This gives the CKSEG0 or KSEG0 address where the kernel is loaded.
On Mon, Mar 26, 2018 at 07:11:51PM +0100, Maciej W. Rozycki wrote:
Make the default for PHYSICAL_START always 64-bit, ensuring that a correct sign-extended value is used if a 32-bit image is loaded by a 64-bit system, and matching how the load address is set in platform Makefile fragments (arch/mips/*/Platform) in the absence of the PHYSICAL_START configuration option.
This looks correct given the defaults in the Makefile fragments. However I presume a 32BIT kernel will produce a 32-bit ELF, in which case the result will be indistinguishable? For other kernel image formats which always use 64-bit pointers perhaps it matters more (if they can be loaded by kexec-tools). uImage is 32-bit ISTR, and our ITB stuff seems to only use 32bit addresses for CONFIG_32BIT. I don't now about other formats.
So unless I hear otherwise I'll probably drop the stable tag and apply for 4.17.
Thanks James
On Tue, 27 Mar 2018, James Hogan wrote:
Make the default for PHYSICAL_START always 64-bit, ensuring that a correct sign-extended value is used if a 32-bit image is loaded by a 64-bit system, and matching how the load address is set in platform Makefile fragments (arch/mips/*/Platform) in the absence of the PHYSICAL_START configuration option.
This looks correct given the defaults in the Makefile fragments. However I presume a 32BIT kernel will produce a 32-bit ELF, in which case the result will be indistinguishable? For other kernel image formats which always use 64-bit pointers perhaps it matters more (if they can be loaded by kexec-tools). uImage is 32-bit ISTR, and our ITB stuff seems to only use 32bit addresses for CONFIG_32BIT. I don't now about other formats.
For ELF it does not matter, but as you say $VMLINUX_LOAD_ADDRESS and $VMLINUX_ENTRY_ADDRESS is needed for software which does not interpret ELF files. However my interpretation is based solely on source examination and the commit description and not actual use of these features. I assume platform Makefile fragments do use 64-bit representation for a reason though.
So unless I hear otherwise I'll probably drop the stable tag and apply for 4.17.
I won't insist on backporting. After all it's the default only and the value can be entered manually if the default does not work.
Maciej
linux-stable-mirror@lists.linaro.org
-
James Hogan -
Maciej W. Rozycki