Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4178324imm; Fri, 18 May 2018 00:12:43 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpNh7VM90uxN1I0q4ERK/GfL550pCI/Vi1BWL3j2EbdN5GllIn2ASnMTj5zHkeJ5X7HZ8bM X-Received: by 2002:a17:902:5ac1:: with SMTP id g1-v6mr8349412plm.43.1526627563540; Fri, 18 May 2018 00:12:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526627563; cv=none; d=google.com; s=arc-20160816; b=hyFb+D/8orfSp1+XueQmeFN4g5EGK7ZDoUKaNhP90uitJOYFVF7uSiHekexb33TsLn ZYeXKy9ZahmzNiP/szRUMBr6JuYbRz6R8I6qypvT7Fpi8PHB/znTpV4cB7VUAuweSs25 voZKavCXkAjyDssoLUlOIhD9TU3JE8qWdG3/LqE2/eTfP8TRSS75NdxlNNTdyR3ztvK6 thGEBcdy908VM78QBKeNyMJs6yArMkGkOFN5K01vVg4qa4NpkC78F4FIOT2JChvka9WW bKgqXnfWQ3XnZgwF3uX8TPBY3GNlEQ4TjuAqfVwchZeBqUHkVUfitZd5hb2QNT7fbOAk 30vw== 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:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=PCNSxREThiu46Hz6ZwLYLd/11t7AOiZc6yG9+1jDeUI=; b=X9wY2M+L6RTEeLRLHG0WVKR5trXka/YKmddX8qOQcfm/cpnFYGrqWnRcS6YkXhIk8c AwQHBQ2/852fWIW4PEWX4UfyLDFa5LKyXjErBXV/kUnZqF2X52DpTFtYIQmcs2zR/+Vl 7n6jvpQ4MJ+yMSs5V4Auq+gHZwKBC/siXJf7oMZMgajGbsW2dPvhLtB78ilJypFvC7WF MLWsP3NTXCdbE4epbO+sAZl80kqR2zNi0ZGF5SBawbdCcSduAJcK97gOieOd7XIMBumh mWf1Xbv1N5R1Z7aygHlcEzegfZvFDRNUkxKMw0Qmpb6g1lQSprK2T18fVGwXIRCdrYop 4wUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=QkW1w20U; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s13-v6si6519374plq.464.2018.05.18.00.12.29; Fri, 18 May 2018 00:12:43 -0700 (PDT) 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=@linaro.org header.s=google header.b=QkW1w20U; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751744AbeERHLh (ORCPT + 99 others); Fri, 18 May 2018 03:11:37 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:37889 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750763AbeERHLg (ORCPT ); Fri, 18 May 2018 03:11:36 -0400 Received: by mail-pg0-f65.google.com with SMTP id n9-v6so2924908pgq.5 for ; Fri, 18 May 2018 00:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PCNSxREThiu46Hz6ZwLYLd/11t7AOiZc6yG9+1jDeUI=; b=QkW1w20Uz9ik+Be0LpKJreVtNoGbA5t/8++GXvcxJS/WOj17tYZuC8QKrir6H4AUPr Rm9VA+lyEYeUp18H1u+VXE+VSxAhHgB4teM2tPeBsmgWVON/WL1ogFlBR8L6Q4/Zgj92 BUNFJygFltowYEaXImNZjhm5Fwen9dxneWIKM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=PCNSxREThiu46Hz6ZwLYLd/11t7AOiZc6yG9+1jDeUI=; b=XtPUMsrMczWRYoLa3/P5iiP8h02jWIBymnh7w+mQzKyqAlMNMMvgGoKAQSzd4fLwAX iD0cwHj/JWZ1JyIDdqNQ7eBpUnQAatnrhhz7V/YE0u9Zqr6vofVZRD2HPGYYvyXrGnlu rEVjsTDswRr49dHD+a+p5PWwKjwOacwq/lOjjEiZ26CtIM/waWSA5/R4OYbkGBkQTr1S sVYVQwdLF99qzNGiuCbRZcR5sMN127aBwQMK9JbfUxZfP1TDraKKrn88X6HGyeVRxQBG 8R45WPtt7XGjnltG8EnGPPVlb3TDwKOw9QBYwQUktCuAWInDhyrpWO8V9UVQi7pYJTH9 zWOA== X-Gm-Message-State: ALKqPwezd9yknumUvuts11f0sUL4V6AINMPKenUtIFlbADlfZ6QPr04A dv7ANe6DVfVmob0WYr2c5534MQ== X-Received: by 2002:a65:4c8d:: with SMTP id m13-v6mr6656176pgt.310.1526627495591; Fri, 18 May 2018 00:11:35 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id n83-v6sm13307573pfi.183.2018.05.18.00.11.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 00:11:34 -0700 (PDT) Date: Fri, 18 May 2018 16:11:35 +0900 From: AKASHI Takahiro To: James Morse Cc: catalin.marinas@arm.com, will.deacon@arm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, ard.biesheuvel@linaro.org, bhsharma@redhat.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 05/11] arm64: kexec_file: load initrd and device-tree Message-ID: <20180518071133.GL2737@linaro.org> Mail-Followup-To: AKASHI Takahiro , James Morse , catalin.marinas@arm.com, will.deacon@arm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, ard.biesheuvel@linaro.org, bhsharma@redhat.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20180425062629.29404-1-takahiro.akashi@linaro.org> <20180425062629.29404-6-takahiro.akashi@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org James, On Tue, May 15, 2018 at 05:20:00PM +0100, James Morse wrote: > Hi Akashi, > > On 25/04/18 07:26, AKASHI Takahiro wrote: > > load_other_segments() is expected to allocate and place all the necessary > > memory segments other than kernel, including initrd and device-tree > > blob (and elf core header for crash). > > While most of the code was borrowed from kexec-tools' counterpart, > > users may not be allowed to specify dtb explicitly, instead, the dtb > > presented by a boot loader is reused. > > (Nit: "a boot loader" -> "the original boot loader") OK > > arch_kimage_kernel_post_load_cleanup() is responsible for freeing arm64- > > specific data allocated in load_other_segments(). > > > > diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c > > index f9ebf54ca247..b3b9b1725d8a 100644 > > --- a/arch/arm64/kernel/machine_kexec_file.c > > +++ b/arch/arm64/kernel/machine_kexec_file.c > > @@ -13,7 +13,26 @@ > > #include > > #include > > #include > > +#include > > #include > > +#include > > +#include > > +#include > > + > > +static int __dt_root_addr_cells; > > +static int __dt_root_size_cells; > > > @@ -55,3 +74,144 @@ int arch_kexec_walk_mem(struct kexec_buf *kbuf, > > > > return ret; > > } > > + > > +static int setup_dtb(struct kimage *image, > > + unsigned long initrd_load_addr, unsigned long initrd_len, > > + char *cmdline, unsigned long cmdline_len, > > + char **dtb_buf, size_t *dtb_buf_len) > > +{ > > + char *buf = NULL; > > + size_t buf_size; > > + int nodeoffset; > > + u64 value; > > + int range_len; > > + int ret; > > + > > + /* duplicate dt blob */ > > + buf_size = fdt_totalsize(initial_boot_params); > > + range_len = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32); > > These two cells values are 0 here. Did you want > arch_kexec_file_init() in patch 7 in this patch? > > Ah, range_len isn't used, so, did you want the cells values and this range_len > thing in in patch 7!? Umm, this problem has long existed since my v1 :) I might better re-think about patch order. > > > + > > + if (initrd_load_addr) > > + buf_size += fdt_prop_len("linux,initrd-start", sizeof(u64)) > > + + fdt_prop_len("linux,initrd-end", sizeof(u64)); > > + > > + if (cmdline) > > + buf_size += fdt_prop_len("bootargs", cmdline_len + 1); > > I can't find where fdt_prop_len() .... oh, patch 7. fdt_prop_len() doesn't look > like the sort of thing that should be created here, but I agree there isn't an > existing API to do this. Will take care of it. > (This must be why powerpc guesses that the fdt won't be more than double in size). > > > > + buf = vmalloc(buf_size); > > + if (!buf) { > > + ret = -ENOMEM; > > + goto out_err; > > + } > > + > > + ret = fdt_open_into(initial_boot_params, buf, buf_size); > > + if (ret) > > + goto out_err; > > + > > + nodeoffset = fdt_path_offset(buf, "/chosen"); > > + if (nodeoffset < 0) > > + goto out_err; > > + > > + /* add bootargs */ > > + if (cmdline) { > > + ret = fdt_setprop(buf, nodeoffset, "bootargs", > > + cmdline, cmdline_len + 1); > > fdt_setprop_string()? OK > > > + if (ret) > > + goto out_err; > > + } > > + > > + /* add initrd-* */ > > + if (initrd_load_addr) { > > + value = cpu_to_fdt64(initrd_load_addr); > > + ret = fdt_setprop(buf, nodeoffset, "linux,initrd-start", > > + &value, sizeof(value)); > > sizeof(value) was assumed to be the same as sizeof(u64) earlier. > fdt_setprop_u64()? OK > > > + if (ret) > > + goto out_err; > > + > > + value = cpu_to_fdt64(initrd_load_addr + initrd_len); > > + ret = fdt_setprop(buf, nodeoffset, "linux,initrd-end", > > + &value, sizeof(value)); > > + if (ret) > > + goto out_err; > > + } > > + > > + /* trim a buffer */ > > + fdt_pack(buf); > > + *dtb_buf = buf; > > + *dtb_buf_len = fdt_totalsize(buf); > > + > > + return 0; > > + > > +out_err: > > + vfree(buf); > > + return ret; > > +} > > While powerpc has some similar code for updating the initrd and cmdline, it > makes different assumptions about the size of the dt, and has different behavior > for memreserve. (looks like we don't expect the initramfs to be memreserved). > Lets leave unifying that stuff where possible for the future. Sure > > +int load_other_segments(struct kimage *image, > > + char *initrd, unsigned long initrd_len, > > + char *cmdline, unsigned long cmdline_len) > > +{ > > + struct kexec_segment *kern_seg; > > + struct kexec_buf kbuf; > > + unsigned long initrd_load_addr = 0; > > + char *dtb = NULL; > > + unsigned long dtb_len = 0; > > + int ret = 0; > > + > > + kern_seg = &image->segment[image->arch.kern_segment]; > > + kbuf.image = image; > > + /* not allocate anything below the kernel */ > > + kbuf.buf_min = kern_seg->mem + kern_seg->memsz; > > > + /* load initrd */ > > + if (initrd) { > > + kbuf.buffer = initrd; > > + kbuf.bufsz = initrd_len; > > + kbuf.memsz = initrd_len; > > > + kbuf.buf_align = 0; > > I'm surprised there initrd has no alignment requirement, MeToo. > but kexec_add_buffer() > rounds this up to PAGE_SIZE. It seems that kimage_load_segment() requires this, but I'm not sure. > > > + /* within 1GB-aligned window of up to 32GB in size */ > > + kbuf.buf_max = round_down(kern_seg->mem, SZ_1G) > > + + (unsigned long)SZ_1G * 32; > > + kbuf.top_down = false; > > + > > + ret = kexec_add_buffer(&kbuf); > > + if (ret) > > + goto out_err; > > + initrd_load_addr = kbuf.mem; > > + > > + pr_debug("Loaded initrd at 0x%lx bufsz=0x%lx memsz=0x%lx\n", > > + initrd_load_addr, initrd_len, initrd_len); > > + } > > + > > + /* load dtb blob */ > > + ret = setup_dtb(image, initrd_load_addr, initrd_len, > > + cmdline, cmdline_len, &dtb, &dtb_len); > > + if (ret) { > > + pr_err("Preparing for new dtb failed\n"); > > + goto out_err; > > + } > > + > > + kbuf.buffer = dtb; > > + kbuf.bufsz = dtb_len; > > + kbuf.memsz = dtb_len; > > + /* not across 2MB boundary */ > > + kbuf.buf_align = SZ_2M; > > + kbuf.buf_max = ULONG_MAX; > > + kbuf.top_down = true; > > + > > + ret = kexec_add_buffer(&kbuf); > > + if (ret) > > + goto out_err; > > + image->arch.dtb_mem = kbuf.mem; > > + image->arch.dtb_buf = dtb; > > + > > + pr_debug("Loaded dtb at 0x%lx bufsz=0x%lx memsz=0x%lx\n", > > + kbuf.mem, dtb_len, dtb_len); > > + > > + return 0; > > + > > +out_err: > > + vfree(dtb); > > + image->arch.dtb_buf = NULL; > > Won't kimage_file_post_load_cleanup() always be called if we return an error > here? Why not leave the free()ing until then? Right. The reason why I left the code here was that we'd better locally clean up all the stuff that were locally allocated if we trivially need to (and can) do so. As it's redundant, I will remove it. Thanks, -Takahiro AKASHI > > > + return ret; > > +} > > > > Thanks, > > James