From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7ED4AC433DB for ; Thu, 4 Feb 2021 23:44:17 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1C34C64FA4 for ; Thu, 4 Feb 2021 23:44:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C34C64FA4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7N/x8w1FuiaHPOSX0VtHnjHmXca8SCABEn8Lrnn1hX8=; b=FtRTWng5A2n6r1Zv8R4sfHoYT ey0Izi2Bk2Lu7bZcQx9Kl23nqCSE/EMNkG2vn3b7QLKUBJCpDvg47b0sxFNg/K05WMOIEJHfpsrXo Bla1YtGBKueF0bZ4n7Ya47YEXVCHWu0fc4UUJAVdoJ1EZdYkZtP2YigjaIDdk2bY3Zkkr+tqQ4LVY OEMsqK4t2B4TXwMpmr4GVTfdNvE5vcgjY5/NkEHWmMRw9ldgjtermJthzRsEFT4mp1kK1PtgrxJ6/ wGV/hrfSBZyuQ3BnVGtiT6TmY6Szd0BzpN+OXpb3+spU8ns8uTFf0FEHuSSBnrWOkQwv25X9/XVSv JBC9A8eww==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l7oHA-0005S2-Tw; Thu, 04 Feb 2021 23:43:04 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l7oH7-0005Rd-Qs for linux-arm-kernel@lists.infradead.org; Thu, 04 Feb 2021 23:43:02 +0000 Received: from [192.168.0.104] (c-73-42-176-67.hsd1.wa.comcast.net [73.42.176.67]) by linux.microsoft.com (Postfix) with ESMTPSA id 34AF920202A2; Thu, 4 Feb 2021 15:42:59 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 34AF920202A2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1612482179; bh=grGpUZ9QXcwEfkJN6PbqbvuH3nL7OZPTJHOmfI5PI3U=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fECv7/DnY4FO0bNMA6WWgLyz+/dHOfMcmq0QU0eiDfZaWbpacyaGvLg5lHbP2ETah s1vwvqeYx29aNMue0LQvultPdSr2bLpZDJ02zpuxHU/CZOkr/bJAqZzOOBkn9n5Q8c s0NHAumYFXMaMVxsQ0YdGOW8lHAYSIIWFqyqW0f8= Subject: Re: [PATCH v16 11/12] powerpc: Use OF alloc and free for FDT To: Rob Herring References: <20210204164135.29856-1-nramas@linux.microsoft.com> <20210204164135.29856-12-nramas@linux.microsoft.com> <503d42ba-89bf-4ad9-9d4c-acb625580f77@linux.microsoft.com> From: Lakshmi Ramasubramanian Message-ID: <9d7c9f2a-fb85-ecd3-3e03-1d324f20d7de@linux.microsoft.com> Date: Thu, 4 Feb 2021 15:42:58 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210204_184302_073141_434E3558 X-CRM114-Status: GOOD ( 34.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Benjamin Herrenschmidt , tao.li@vivo.com, Mimi Zohar , Paul Mackerras , vincenzo.frascino@arm.com, Frank Rowand , Sasha Levin , Michael Ellerman , Masahiro Yamada , James Morris , "AKASHI, Takahiro" , linux-arm-kernel , Catalin Marinas , "Serge E. Hallyn" , devicetree@vger.kernel.org, Pavel Tatashin , Will Deacon , Prakhar Srivastava , Hsin-Yi Wang , Allison Randal , Christophe Leroy , Matthias Brugger , balajib@linux.microsoft.com, dmitry.kasatkin@gmail.com, "linux-kernel@vger.kernel.org" , James Morse , Greg Kroah-Hartman , Joe Perches , linux-integrity@vger.kernel.org, linuxppc-dev , Thiago Jung Bauermann Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2/4/21 3:36 PM, Rob Herring wrote: > 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. ok > >> 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. That is good information. Thanks. > >>>> 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. ok - I'll use DTB_EXTRA_SPACE for the fdt allocation. > > Also, I would like for 'initial_boot_params' to be private ultimately, > so removing any references is helpful. ok > >> And, for powerpc leave the remaining code in setup_new_fdt_ppc64(). > > Right. ok thanks, -lakshmi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel