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.2 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 9FF07C433E0 for ; Thu, 4 Feb 2021 23:44:54 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 D3F2064FA4 for ; Thu, 4 Feb 2021 23:44:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D3F2064FA4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4DWwBq6MWlzDqRr for ; Fri, 5 Feb 2021 10:44:51 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linux.microsoft.com (client-ip=13.77.154.182; helo=linux.microsoft.com; envelope-from=nramas@linux.microsoft.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.a=rsa-sha256 header.s=default header.b=fECv7/Dn; dkim-atps=neutral Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lists.ozlabs.org (Postfix) with ESMTP id 4DWw8j5qRQzDqB9 for ; Fri, 5 Feb 2021 10:43:01 +1100 (AEDT) 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-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , tao.li@vivo.com, Mimi Zohar , Paul Mackerras , vincenzo.frascino@arm.com, Frank Rowand , Sasha Levin , 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 Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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