Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp8331633ybl; Thu, 16 Jan 2020 14:47:25 -0800 (PST) X-Google-Smtp-Source: APXvYqxhs5rXEvkiqHJ3s8WRphCcamxh2O10hsXV24793b/foSwZTGhI57qbeBQVDX2Js026Fs3s X-Received: by 2002:a9d:d06:: with SMTP id 6mr1152032oti.176.1579214845357; Thu, 16 Jan 2020 14:47:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579214845; cv=none; d=google.com; s=arc-20160816; b=zKLUilQhd3v/c4EwLFk8BI3sasoHLMTbNuwduQhK3yeeQJ3q4okxVNy9AyxMC/sREE NE4baOwfNAeeH/42xfSJiX11ZU6b92TgH9eDFo4hl2aJqNNfPt9CI6ljkf8McNXVlx0+ Qyq3MxIcK8qJpNrVJfkP+3GWFdKtSiiJl57YAl9RtM7Z5GbLFqe+FQ0Hxck7Fj7uI36M Wf+FIJm9Dfb4YU7lrvmfbEHL8s+bPAgaZ5jMOe/l+bJqzo5qFfCCYzqveYp/87nuUf2i lI4LT6f9Ncp66tfv9hb5r8E2BYRNUPuk/LcdR566yGBZDrDy/RbYQrjb9uaZjl3ls2QA tKOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:to :from:date:dkim-signature; bh=cxOFacbCGN2pv3OGFwDi/4GJYsVYWImo56w8KJDuvNw=; b=DREEGIodgxsSgOvSy6asiQiVMwny0drISb7TqfmmzGUZ6fE3BmDHau7azr1Yus0ASN ZdG6B9laWjU4wPGRMmgWTx2+Wnyp9cmkUfX6QPKewltzpLnl63tjr69IAFMvJMLM8ePo pO3lIB/GaYvR8w3PZ4zYj813cx8b/DtdFTYFarc13ZL/MV8oPkgvZuykLEYH0MfZZVbl rkkXDC38CbTEsyuBTkoPG4tj321CKej9sk5QaZ7cu4td5KeT5//NliuEY8kuDauFHtYW eQtAcD2gLuvienVSKI6+H2gt5xiRfWWnYgEHq2e8yN2F0uT4s8aWXHtxrzvUh+gBa78r OJ4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=y1Wk+36g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b133si12936057oif.244.2020.01.16.14.47.13; Thu, 16 Jan 2020 14:47:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=y1Wk+36g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2395068AbgAPSJG (ORCPT + 99 others); Thu, 16 Jan 2020 13:09:06 -0500 Received: from mail.kernel.org ([198.145.29.99]:45780 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2395058AbgAPSJE (ORCPT ); Thu, 16 Jan 2020 13:09:04 -0500 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1D525214AF; Thu, 16 Jan 2020 18:09:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579198142; bh=G12bYRjcFudffpQ1Inc1ks16rEJngpLF0eu9Bib/8YI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=y1Wk+36g6x6dqMQXtUbMYxKQj6vISCydPq/80JUNhvRBRQlZvOMlp8qwo9f/1hK/9 6ViaY6kF/wqqJdCtP2KA73CyC4RcI1702MEccjKN559ZrT75cKQmGVxCoLrhF37W4D ydKODBdVJNUDGpAtZxoVBfhyqK/3Lni8IIbkruIU= Date: Thu, 16 Jan 2020 18:08:58 +0000 From: Will Deacon To: AKASHI Takahiro , Pavel Tatashin , Catalin Marinas , Will Deacon , robh+dt@kernel.org, frowand.list@gmail.com, Bhupesh Sharma , kexec mailing list , LKML , James Morse , Linux ARM Subject: Re: [PATCH v4 2/2] arm64: kexec_file: add crash dump support Message-ID: <20200116180857.GA22420@willie-the-truck> References: <20191216021247.24950-1-takahiro.akashi@linaro.org> <20191216021247.24950-3-takahiro.akashi@linaro.org> <20200108174839.GB21242@willie-the-truck> <20200109004654.GA28530@linaro.org> <20200109083254.GA7280@willie-the-truck> <20200110160549.GA25437@willie-the-truck> <20200113112105.GB2337@willie-the-truck> <20200114053825.GC28530@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200114053825.GC28530@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 14, 2020 at 02:38:26PM +0900, AKASHI Takahiro wrote: > On Mon, Jan 13, 2020 at 11:21:06AM +0000, Will Deacon wrote: > > On Fri, Jan 10, 2020 at 11:19:16AM -0500, Pavel Tatashin wrote: > > > On Fri, Jan 10, 2020 at 11:05 AM Will Deacon wrote: > > > > On Thu, Jan 09, 2020 at 08:32:54AM +0000, Will Deacon wrote: > > > > > On Thu, Jan 09, 2020 at 09:46:55AM +0900, AKASHI Takahiro wrote: > > > > > > On Wed, Jan 08, 2020 at 05:48:39PM +0000, Will Deacon wrote: > > > > > > > On Mon, Dec 16, 2019 at 11:12:47AM +0900, AKASHI Takahiro wrote: > > > > > > > > diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h > > > > > > > > index 12a561a54128..d24b527e8c00 100644 > > > > > > > > --- a/arch/arm64/include/asm/kexec.h > > > > > > > > +++ b/arch/arm64/include/asm/kexec.h > > > > > > > > @@ -96,6 +96,10 @@ static inline void crash_post_resume(void) {} > > > > > > > > struct kimage_arch { > > > > > > > > void *dtb; > > > > > > > > unsigned long dtb_mem; > > > > > > > > + /* Core ELF header buffer */ > > > > > > > > + void *elf_headers; > > > > > > > > + unsigned long elf_headers_mem; > > > > > > > > + unsigned long elf_headers_sz; > > > > > > > > }; > > > > > > > > > > > > > > This conflicts with the cleanup work from Pavel. Please can you check my > > > > > > > resolution? [1] > > > > > > > > > > > > I don't know why we need to change a type of dtb_mem, > > > > > > otherwise it looks good. > > > > > > > > > > > > (I also assume that you notice that kimage_arch is of no use for kexec.) > > > > > > > > > > Yes, that's why I'd like the resolution checked. If you reckon it's cleaner > > > > > to drop Pavel's patch altogether in light of your changes, we can do that > > > > > instead. > > > > > > > > > > Thoughts? > > > > > > > > Well, I've reverted the cleanup patch so please shout if you'd prefer > > > > something else. > > > > > > As I understand, the only concern was the type change for dtb_mem. > > > This was one of the review comments for my patch > > > https://lore.kernel.org/lkml/20191204155938.2279686-21-pasha.tatashin@soleen.com/ > > > > > > (I believe it was from Marc Zyngier), I add a number of new fields, > > > and they all should be phys_addr_t, this is why I change dtb_mem to > > > phys_addr_t to be consistent. > > > > Sure, but I've only queued the first part of your series and that cleanup > > patch doesn't make a lot of sense when applied against Akashi's work. I'm > > happy to take stuff on top if you both agree to it, but having half of the > > struct use unsigned long and the other half use phys_addr_t is messy. > > Logically, whether dtb_mem is a "unsigned long" or phys_addr_t doesn't > matter unless the kernel is compiled under LLP64. > As far as the existing kexec code, either generic or arm64-specific, > is concerned, however, "unsigned long is widely used as a physical address > (For example, see kexec_buf definition) over the code. > > (Oops, reboot_code_buffer_phys is a phys_addr_t :) > > So as long as my kexec_file (and associated kdump) patch comes first > before Pavel's, I'd like to keep using "unsigned long". > Then, you can change "unsigned long" to phys_addr_t in your patch > for whatever reason it is. > > Please note that, if you want to do that, it would be better to modify > not only kimage_arch but also all the occurrences of "unsigned long" > to phys_addr_t for maintaining the integrity. > > In addition, in my kexec_file kdump code, I still believe that > "#ifdef CONFIG_KEXEC_FILE" should stay before the definition of > kimage_arch as kimage_arch is of no use for normal kexec code. > > Again, > "#ifdef" statement may be moved forward once additional fields be > added later by Pavel's patch, say, "[PATCH v8 15/25] arm64: kexec: > move relocation function setup" for any reason. > > I believe that this way gives us a logical and consistent view of > history of changes. > Make sense? This is a bit much to stick in a merge commit, so I'll stick with the revert for now and you can send patches on top if you want it changed. Cheers, Will