Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1613299pxb; Thu, 4 Feb 2021 18:36:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJyuKCxz7uEKdNUFmvsJ1ok3btA1MkbfeI+qDm81GZDfnS0oxYkpQhyInvVOsj/NMY9+IzMs X-Received: by 2002:a17:906:e03:: with SMTP id l3mr1944165eji.64.1612492616028; Thu, 04 Feb 2021 18:36:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612492616; cv=none; d=google.com; s=arc-20160816; b=fcoaLTt/giMQeGOfsOWqfEdBA3JqyLzQtKwSBQLqA34PhJAqhty7MSqjVRUWdxK9Kv 1OCslT1SYs9tIVPVuBWLDUC5RVsEUi2nj5wDG4FuestBr7GFbIlM7C8VL+o9K2NokBfD 9acGL0igVrqe19cL2iQWEv3ZambWC2HnoIefoG9o7jlo0AOR+FDNYSvkCyMi/+yIYkfr 9K1rB7DWUlKNuysE6Cq3FUxn6RwWO564e92Dp1jcp93rSEnUTKT7eS2kEjwX09/M97jP t+vKxqB7jKzORrDtSHUEZbJbFsyLvqaFIPcpmmtPCqPjFcgtpN/Rs5K4stGy3OYjWC8P gjgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=gSIxG3Ao9pQj7+5lTQDRZE20K2eI/OpVc8vMPNr5c6k=; b=C+73bmPdowgU6IcvNIu98YQG28lsjm6xPk1FGvIXB+BnYGn5Aboyggkmt48qLchHD/ m9vKJjaaLnsisbmxO4xpXZv/pXUWvtQi6rMp7BeAAuLhzlQAj3ovvCeneYip+j9h/FP3 fw532lznGivpe9hdluUKAmdESMsLd1t0eb0mXYftlSJwtf/80RwQNZmLmkpU0WBLVmm3 M9ZVDJWaPyR1RX1I8oZktt7pRZhBwg034QLAfCFIeBZUqIzenW95u/X1ZRUZfhbSUVK7 eP73Ev6Xo/awGimjgxyQ2agTlIn9fRit3dDCg/Ro/ERO2oQ2bfEsuEFvGeAQeqO5UGbo iL8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YPPg5EW6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id jg13si5124675ejc.669.2021.02.04.18.35.57; Thu, 04 Feb 2021 18:36:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YPPg5EW6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S230315AbhBDXhS (ORCPT + 99 others); Thu, 4 Feb 2021 18:37:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:43098 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230039AbhBDXhL (ORCPT ); Thu, 4 Feb 2021 18:37:11 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 61CA464FA8; Thu, 4 Feb 2021 23:36:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612481789; bh=7OrFkXLdbalgz/5cOchaHpPT+jU0NC7Afg58VcdimLs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=YPPg5EW6JOGrAT/q879L8vMHpxyT4uq+HoPwYvl6aYLvdimUUOvA5QdePEHRQTFdH iYfZkMeDy3zy9OQyNvg+AR+tPjBv17eIYlyggyCFQdC5pTZDND8Q2kuiCBRqF4gGyZ /Cf9dw/uvuv9WPsJuPPrKot1KCtQdLZQn6b10t4VnHSkrSBokfTGY5JRY4MoWrqlmA Ovcug+2UnEXOUf7f0/3+vE2XwiTeHSAeF8yQuJRPCNiC4RIY9XjsqfgVfwX0GbgGvs NxNgO4+8h91dtOrMjLiXvdiuEBUnnf7ykZqeKMCnebJH7WvyOSX6i3hYNfxlGrW9xE albP0Hyrl/xKQ== Received: by mail-ed1-f50.google.com with SMTP id q2so6538717edi.4; Thu, 04 Feb 2021 15:36:29 -0800 (PST) X-Gm-Message-State: AOAM53128uYzQRjiyPKfi4KTWnjXQY3fK0Ok1U8ULv+nWQbuL1QZxuSE DKn04kA7d9/8CkiuOXnUivza5gD/2bKXXTbnNQ== X-Received: by 2002:a17:906:af41:: with SMTP id ly1mr1339104ejb.525.1612481787108; Thu, 04 Feb 2021 15:36:27 -0800 (PST) MIME-Version: 1.0 References: <20210204164135.29856-1-nramas@linux.microsoft.com> <20210204164135.29856-12-nramas@linux.microsoft.com> <503d42ba-89bf-4ad9-9d4c-acb625580f77@linux.microsoft.com> In-Reply-To: <503d42ba-89bf-4ad9-9d4c-acb625580f77@linux.microsoft.com> From: Rob Herring Date: Thu, 4 Feb 2021 17:36:15 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v16 11/12] powerpc: Use OF alloc and free for FDT To: Lakshmi Ramasubramanian Cc: Mimi Zohar , Thiago Jung Bauermann , "AKASHI, Takahiro" , Greg Kroah-Hartman , Will Deacon , Joe Perches , Catalin Marinas , Michael Ellerman , James Morse , Sasha Levin , Benjamin Herrenschmidt , Paul Mackerras , Frank Rowand , vincenzo.frascino@arm.com, Mark Rutland , dmitry.kasatkin@gmail.com, James Morris , "Serge E. Hallyn" , Pavel Tatashin , Allison Randal , Masahiro Yamada , Bhupesh Sharma , Matthias Brugger , Hsin-Yi Wang , tao.li@vivo.com, Christophe Leroy , Prakhar Srivastava , balajib@linux.microsoft.com, linux-integrity@vger.kernel.org, "linux-kernel@vger.kernel.org" , linux-arm-kernel , devicetree@vger.kernel.org, linuxppc-dev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 4, 2021 at 5:23 PM Lakshmi Ramasubramanian wrote: > > On 2/4/21 11:26 AM, Rob Herring wrote: > > On Thu, Feb 4, 2021 at 10:42 AM Lakshmi Ramasubramanian > > wrote: > >> > >> of_alloc_and_init_fdt() and of_free_fdt() have been defined in > >> drivers/of/kexec.c to allocate and free memory for FDT. > >> > >> Use of_alloc_and_init_fdt() and of_free_fdt() to allocate and > >> initialize the FDT, and to free the FDT respectively. > >> > >> powerpc sets the FDT address in image_loader_data field in > >> "struct kimage" and the memory is freed in > >> kimage_file_post_load_cleanup(). This cleanup function uses kfree() > >> to free the memory. But since of_alloc_and_init_fdt() uses kvmalloc() > >> for allocation, the buffer needs to be freed using kvfree(). > > > > You could just change the kexec core to call kvfree() instead. > > > > >> Define "fdt" field in "struct kimage_arch" for powerpc to store > >> the address of FDT, and free the memory in powerpc specific > >> arch_kimage_file_post_load_cleanup(). > > > > However, given all the other buffers have an explicit field in kimage > > or kimage_arch, changing powerpc is to match arm64 is better IMO. > > Just to be clear: > I'll leave this as is - free FDT buffer in powerpc's > arch_kimage_file_post_load_cleanup() to match arm64 behavior. Yes. > Will not change "kexec core" to call kvfree() - doing that change would > require changing all architectures to use kvmalloc() for > image_loader_data allocation. Actually, no. AIUI, kvfree() can be used whether you used kvmalloc, vmalloc, or kmalloc for the alloc. > >> Signed-off-by: Lakshmi Ramasubramanian > >> Suggested-by: Rob Herring > >> Suggested-by: Thiago Jung Bauermann > >> --- > >> arch/powerpc/include/asm/kexec.h | 2 ++ > >> arch/powerpc/kexec/elf_64.c | 26 ++++++++++++++++---------- > >> arch/powerpc/kexec/file_load_64.c | 3 +++ > >> 3 files changed, 21 insertions(+), 10 deletions(-) > >> > >> diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h > >> index 2c0be93d239a..d7d13cac4d31 100644 > >> --- a/arch/powerpc/include/asm/kexec.h > >> +++ b/arch/powerpc/include/asm/kexec.h > >> @@ -111,6 +111,8 @@ struct kimage_arch { > >> unsigned long elf_headers_mem; > >> unsigned long elf_headers_sz; > >> void *elf_headers; > >> + > >> + void *fdt; > >> }; > >> > >> char *setup_kdump_cmdline(struct kimage *image, char *cmdline, > >> diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c > >> index d0e459bb2f05..51d2d8eb6c1b 100644 > >> --- a/arch/powerpc/kexec/elf_64.c > >> +++ b/arch/powerpc/kexec/elf_64.c > >> @@ -19,6 +19,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> #include > >> #include > >> #include > >> @@ -32,7 +33,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf, > >> unsigned int fdt_size; > >> unsigned long kernel_load_addr; > >> unsigned long initrd_load_addr = 0, fdt_load_addr; > >> - void *fdt; > >> + void *fdt = NULL; > >> const void *slave_code; > >> struct elfhdr ehdr; > >> char *modified_cmdline = NULL; > >> @@ -103,18 +104,12 @@ static void *elf64_load(struct kimage *image, char *kernel_buf, > >> } > >> > >> fdt_size = fdt_totalsize(initial_boot_params) * 2; > >> - fdt = kmalloc(fdt_size, GFP_KERNEL); > >> + fdt = of_alloc_and_init_fdt(fdt_size); > >> if (!fdt) { > >> pr_err("Not enough memory for the device tree.\n"); > >> ret = -ENOMEM; > >> goto out; > >> } > >> - ret = fdt_open_into(initial_boot_params, fdt, fdt_size); > >> - if (ret < 0) { > >> - pr_err("Error setting up the new device tree.\n"); > >> - ret = -EINVAL; > >> - goto out; > >> - } > >> > >> ret = setup_new_fdt_ppc64(image, fdt, initrd_load_addr, > > > > The first thing this function does is call setup_new_fdt() which first > > calls of_kexec_setup_new_fdt(). (Note, I really don't understand the > > PPC code split. It looks like there's a 32-bit and 64-bit split, but > > 32-bit looks broken to me. Nothing ever calls setup_new_fdt() except > > setup_new_fdt_ppc64()). The arm64 version is calling > > of_alloc_and_init_fdt() and then of_kexec_setup_new_fdt() directly. > > > > So we can just make of_alloc_and_init_fdt() also call > > of_kexec_setup_new_fdt() (really, just tweak of_kexec_setup_new_fdt do > > the alloc and copy). > ok - will move fdt allocation into of_kexec_setup_new_fdt(). > > I don't think the architecture needs to pick the > > size either. It's doubtful that either one is that sensitive to the > > amount of extra space. > I am not clear about the above comment - > are you saying the architectures don't need to pass FDT size to the > alloc function? > > arm64 is adding command line string length and some extra space to the > size computed from initial_boot_params for FDT Size: > > buf_size = fdt_totalsize(initial_boot_params) > + cmdline_len + DTB_EXTRA_SPACE; > > powerpc is just using twice the size computed from initial_boot_params > > fdt_size = fdt_totalsize(initial_boot_params) * 2; > > I think it would be safe to let arm64 and powerpc pass the required FDT > size, along with the other params to of_kexec_setup_new_fdt() - and in > this function we allocate FDT and set it up. It's pretty clear that someone just picked something that 'should be enough'. The only thing I can guess for the difference is that arm DT's tend to be a bit larger. So doubling the size would be even more excessive. Either way, we're talking 10s kB to few 100kB. I'd go with DTB_EXTRA_SPACE and we can bump it up if someone has problems. Also, I would like for 'initial_boot_params' to be private ultimately, so removing any references is helpful. > And, for powerpc leave the remaining code in setup_new_fdt_ppc64(). Right. Rob