From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Subject: Re: [PATCH v9 07/11] arm64: kexec_file: add crash dump support From: James Morse References: <20180425062629.29404-1-takahiro.akashi@linaro.org> <20180425062629.29404-8-takahiro.akashi@linaro.org> Message-ID: <3d70c7d1-4985-a427-ecc6-a7edc84edfff@arm.com> Date: Wed, 16 May 2018 09:34:41 +0100 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: AKASHI Takahiro Cc: herbert@gondor.apana.org.au, bhe@redhat.com, ard.biesheuvel@linaro.org, catalin.marinas@arm.com, bhsharma@redhat.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, dhowells@redhat.com, arnd@arndb.de, linux-arm-kernel@lists.infradead.org, kexec@lists.infradead.org, dyoung@redhat.com, davem@davemloft.net, vgoyal@redhat.com Hi Akashi, On 15/05/18 18:11, James Morse wrote: > On 25/04/18 07:26, AKASHI Takahiro wrote: >> Enabling crash dump (kdump) includes >> * prepare contents of ELF header of a core dump file, /proc/vmcore, >> using crash_prepare_elf64_headers(), and >> * add two device tree properties, "linux,usable-memory-range" and >> "linux,elfcorehdr", which represent repsectively a memory range >> to be used by crash dump kernel and the header's location >> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c >> index 37c0a9dc2e47..ec674f4d267c 100644 >> --- a/arch/arm64/kernel/machine_kexec_file.c >> +++ b/arch/arm64/kernel/machine_kexec_file.c >> @@ -76,6 +81,78 @@ int arch_kexec_walk_mem(struct kexec_buf *kbuf, >> +static void fill_property(void *buf, u64 val64, int cells) >> +{ >> + u32 val32; >> + >> + if (cells == 1) { >> + val32 = cpu_to_fdt32((u32)val64); >> + memcpy(buf, &val32, sizeof(val32)); >> + } else { > >> + memset(buf, 0, cells * sizeof(u32) - sizeof(u64)); >> + buf += cells * sizeof(u32) - sizeof(u64); > > Is this trying to clear the 'top' cells and shuffle the pointer to point at the > 'bottom' 2? I'm pretty sure this isn't endian safe. It came to me at 2am: this only works on big-endian, which is exactly what you want as that is the DT format. > Do we really expect a system to have #address-cells > 2? Thanks, James _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec