Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754211AbdHYBBH (ORCPT ); Thu, 24 Aug 2017 21:01:07 -0400 Received: from mail-pg0-f53.google.com ([74.125.83.53]:35527 "EHLO mail-pg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753838AbdHYBBF (ORCPT ); Thu, 24 Aug 2017 21:01:05 -0400 Date: Fri, 25 Aug 2017 10:00:59 +0900 From: AKASHI Takahiro To: Mark Rutland Cc: catalin.marinas@arm.com, will.deacon@arm.com, bauerman@linux.vnet.ibm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, akpm@linux-foundation.org, mpe@ellerman.id.au, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, ard.biesheuvel@linaro.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 08/14] arm64: kexec_file: create purgatory Message-ID: <20170825010054.GC6434@akashi-kouhiroshi-no-MacBook-Air.local> Mail-Followup-To: AKASHI Takahiro , Mark Rutland , catalin.marinas@arm.com, will.deacon@arm.com, bauerman@linux.vnet.ibm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, akpm@linux-foundation.org, mpe@ellerman.id.au, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, ard.biesheuvel@linaro.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20170824081811.19299-1-takahiro.akashi@linaro.org> <20170824081811.19299-9-takahiro.akashi@linaro.org> <20170824165617.GC29665@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170824165617.GC29665@leverpostej> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1966 Lines: 53 On Thu, Aug 24, 2017 at 05:56:17PM +0100, Mark Rutland wrote: > On Thu, Aug 24, 2017 at 05:18:05PM +0900, AKASHI Takahiro wrote: > > This is a basic purgtory, or a kind of glue code between the two kernel, > > for arm64. We will later add a feature of verifying a digest check against > > loaded memory segments. > > > > arch_kexec_apply_relocations_add() is responsible for re-linking any > > relative symbols in purgatory. Please note that the purgatory is not > > an executable, but a non-linked archive of binaries so relative symbols > > contained here must be resolved at kexec load time. > > Despite that arm64_kernel_start and arm64_dtb_addr are only such global > > variables now, arch_kexec_apply_relocations_add() can manage more various > > types of relocations. > > Why does the purgatory code need to be so complex? > > Why is it not possible to write this as position-independent asm? I don't get your point, but please note that these values are also re-written by the 1st kernel when it loads the 2nd kernel and so they must appear as globals. > > +/* > > + * Apply purgatory relocations. > > + * > > + * ehdr: Pointer to elf headers > > + * sechdrs: Pointer to section headers. > > + * relsec: section index of SHT_RELA section. > > + * > > + * Note: > > + * Currently R_AARCH64_ABS64, R_AARCH64_LD_PREL_LO19 and R_AARCH64_CALL26 > > + * are the only types to be generated from purgatory code. > > Is this all that has been observed, or is this ensured somehow? It was observed by inserting a debug print message in this function, I'm not sure whether we can restrict only those three types. > The arch_kexec_apply_relocations_add() function below duplicates a lot > of logic that already exists in the arm64 module loader's > apply_relocate_add() function. > > Please reuse that code. Having a duplicate or alternative implementation > is just asking for subtle bugs. Okey, I'll look at it. Thanks, -Takahiro AKASHI > Thanks, > Mark.