Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4201515imm; Fri, 18 May 2018 00:43:37 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoVYdXLeeR0p19UTtlptOOi0cJ46s/aU10GmsyqCxpLwN16kzdZpnDTLpsHNoKUqHRY0UtE X-Received: by 2002:a62:303:: with SMTP id 3-v6mr8299917pfd.255.1526629417097; Fri, 18 May 2018 00:43:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526629417; cv=none; d=google.com; s=arc-20160816; b=mhB7RgggrD+dpYOtn7gcrfnvd7Sht97JzcUoWfTj9YsRVt4RxfLzv4xhqcq6Ew87Ay mGtXxo1gTlRQkYlaUtldPBzgY6okqQizW2arnhj7bAOMEZdtYzm9KDz7mFVmHAyLtepn 502nGXbZvCvBYkEWge/Yb5ncdjne+5PbT7aiDjHPa/4AfUhCWUk1k3RpbCxaBNxuV8e3 gVahKtVzHzf2cWr514avdpzE3qUAtQa3VRnS+qVVnPHCDVIEL9xnqDHgHEPcYbW9DUja 2Er6xKj0yMpu0jy8MRk21XivukJPdGOKG/E4qKZAD9op0MfyUg4FsZbLZrQ/MZo9Rz1m b4og== 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:to:from:date:dkim-signature :arc-authentication-results; bh=Wzi+K7HFkYYoZ/4kyvTEcS2lmQH2G8hs7ejgm5x/7MA=; b=LMtQpAQt7Iz4dvS6nfp18wCmAeE4udRfcdFRM4/dhnPVeKcphz1ADmDwQRrZYtF2Uj Ic3LG8dWA1qVwoyRjDB8Fa5TsM7SkhBOofOyikAN+lSj+sOXYt5QKWthdjWz0aUKLz9a 8LfJCQAK6YIvyc6x9X1Dc7MRJlXlBstFJdvBTiyK7VTPBkEdsun0QPioVA5GDoaGzgwN /hY+Ctrv4S7jBVBMEyGVFFFfbr6sODDALHcGAfjDIwlSSXhH0bU/jJjChjudYiw+im7h 7hlq4WnVtpN9EqTd7l3O+sRJ//tnmx9vROtcRXHJWjGKVcCgFft4jt+ZAfVvkPXbwGJW mEHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=QwO+Taze; 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 31-v6si7013642plh.552.2018.05.18.00.43.23; Fri, 18 May 2018 00:43:37 -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=QwO+Taze; 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 S1751914AbeERHmL (ORCPT + 99 others); Fri, 18 May 2018 03:42:11 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:36418 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751405AbeERHmH (ORCPT ); Fri, 18 May 2018 03:42:07 -0400 Received: by mail-pl0-f68.google.com with SMTP id v24-v6so4102482plo.3 for ; Fri, 18 May 2018 00:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Wzi+K7HFkYYoZ/4kyvTEcS2lmQH2G8hs7ejgm5x/7MA=; b=QwO+Tazed2xatu0oIcQo26N1UHWOfRTqIP0gSZugZqlQjTVn0MAUHGoK2lTyJEdI54 FzjIdeIjPhDPdogV5Wx5DgIRfg8Em1/RW+fDQfCU8mP14VDXPutk0yq3bGF8ftDIlf2C SPkqMsG/KWz2REOeVTubVIAJvI3JbfYGPx0qU= 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:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=Wzi+K7HFkYYoZ/4kyvTEcS2lmQH2G8hs7ejgm5x/7MA=; b=TxG2sau2nF8/lJcvsbl64ozY8+25y8HdvPlHoqXYuJVHSyXJ1kPorEKebG1cQMB27y TBY+rQb8HnBMYiK+gJtKTfnFkZ0ZkN9CzDZe45qz/hmlcZkJRqvY85auxHX05DS3Lhfy DLe1MJHyeoyQ9HUloN6mFyHMmyNDkz3MJV0rytvnPwS7SeHRpo0BALPzSw0s60zakpxL C8JtYEbxQWroFux04JRgksP6NibtZNNgYUjZyx0JcC3bwJKgUWwf2jqmZKJneoKmLou0 Tshc1n7UcI0uTleRc6TILQ9hE7uY8f2QhUwAsXaku1X+wg77lWbsPION6FghZc/dZjzQ W1DA== X-Gm-Message-State: ALKqPwfgW77bpnnlXN6mXoe+qOSjurvODZM2W5Js6UDo4ruIBGLRY0nZ rYIflKYCjib3MspLHHx1btoGyg== X-Received: by 2002:a17:902:8647:: with SMTP id y7-v6mr8330655plt.86.1526629326858; Fri, 18 May 2018 00:42:06 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id 203-v6sm12117508pfz.131.2018.05.18.00.42.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 00:42:06 -0700 (PDT) Date: Fri, 18 May 2018 16:42:04 +0900 From: AKASHI Takahiro To: 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 Subject: Re: [PATCH v9 05/11] arm64: kexec_file: load initrd and device-tree Message-ID: <20180518074203.GM2737@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> <20180518071133.GL2737@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180518071133.GL2737@linaro.org> 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 On Fri, May 18, 2018 at 04:11:35PM +0900, AKASHI Takahiro wrote: > 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 cmdline_len is passed by system call, kexec_file_load(), and this means that we can't believe that cmdline is always terminated with '\0'. > > > > > > + 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. will remove only "image->arch.dtb_buf = NULL." > Thanks, > -Takahiro AKASHI > > > > > > + return ret; > > > +} > > > > > > > > Thanks, > > > > James