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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CC7CCCA0EC4 for ; Mon, 11 Aug 2025 19:35:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=FGcpL4XArIt7yLfG+gYB1MiWLPOxQ4ZNemVVA5X7j/Q=; b=1ufMlfd1AKIBy10U5LofSRMul/ aK0UxoysaQkLlOyfwXMYN2yMtHiZuTNEt9asIY/TDi6ei8ztDonaGlLLiPtNb0G26MnKoJqWUMfdZ 1rBzfCB+AwbmGoriAO4mf/pM7BsLz5oHTqsWp9z+h46VUJ0U77XX/RvCSb7U7O9fK9y10ADQ/tfpv XxPGBi7EbmEXHHu+93aSbVLckzbWWDeHGx6Q8SL0zjIeAwOI8H9fyIPANqdwJi5J+615jIrHbOBcK meMRQMEfTQVhqaIlE2kiGQO6eJhrm6T0DjCYLYI/W1LWGMtg1k8rqMnJe0AA//UWG8dOebpDJOZov T+iuT1tA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1ulYJC-00000008wGk-1GJ5; Mon, 11 Aug 2025 19:35:50 +0000 Received: from layka.disroot.org ([178.21.23.139]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1ulWnZ-00000008cEA-3k6Z for kexec@lists.infradead.org; Mon, 11 Aug 2025 17:59:07 +0000 Received: from mail01.disroot.lan (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 0426C21B02; Mon, 11 Aug 2025 19:59:04 +0200 (CEST) X-Virus-Scanned: SPAM Filter at disroot.org Received: from layka.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavis, port 10024) with ESMTP id EjxmdH4iwM9G; Mon, 11 Aug 2025 19:59:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1754935102; bh=5IrkZTtsgWCXjSHQu/naac3Uo1zbNi01U44yoOk6NqY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=LX3nddLIxM6PFJvSRQwrny2CdEJXN70Bi1TI3F5riMwPM4v4mM/cYzmS/oBqxMhyw l8CN3KYcQc2LyMq/Ee+gtYNLfk8QO1fiKndHRDLeq5XKhDPGCdcEimI+CCAGdQzdXA WvYv4onIzhBgoGmExJoichZyRQeotnBmmtgMWf23N2GRMFiYTwguqjeKo2+0ERs39h 7xiva9IG1nGTD5ekb0b3w3c9beqmcQPpJ9LilI/sFikmCIZvWAyN4znEd/iJvFWCDt 3btP5O61ERiKG5zucJB1IiIDN2igm2IS3G+yhzTwPjiv1qQ+MjnwR5WgES9VFBn9Kr Ubl8hG4lXGp+g== Date: Mon, 11 Aug 2025 17:58:00 +0000 From: Yao Zi To: Youling Tang , Huacai Chen Cc: WANG Xuerui , Baoquan He , kexec@lists.infradead.org, loongarch@lists.linux.dev, linux-kernel@vger.kernel.org, Youling Tang Subject: Re: [PATCH 3/6] LoongArch/kexec_file: Add initrd loading Message-ID: References: <20250811092659.14903-1-youling.tang@linux.dev> <20250811092659.14903-4-youling.tang@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250811092659.14903-4-youling.tang@linux.dev> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250811_105906_369190_84B77393 X-CRM114-Status: GOOD ( 25.89 ) X-BeenThere: kexec@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "kexec" Errors-To: kexec-bounces+kexec=archiver.kernel.org@lists.infradead.org On Mon, Aug 11, 2025 at 05:26:56PM +0800, Youling Tang wrote: > From: Youling Tang > > Add inird loading support and pass it to the second kernel via the > cmdline 'initrd=start,size'. I think This won't work if the exec'ed kernel enables CONFIG_CMDLINE_FORCE. Is it possible to mimic libstub's behavior of installing a configuration table LINUX_EFI_INITRD_MEDIA_GUID? > > Signed-off-by: Youling Tang > --- > arch/loongarch/kernel/machine_kexec_file.c | 71 ++++++++++++++++++++++ > 1 file changed, 71 insertions(+) > > diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c > index bc91ae0afa4c..e1240644f529 100644 > --- a/arch/loongarch/kernel/machine_kexec_file.c > +++ b/arch/loongarch/kernel/machine_kexec_file.c > @@ -34,13 +34,84 @@ int arch_kimage_file_post_load_cleanup(struct kimage *image) > return kexec_image_post_load_cleanup_default(image); > } > > +/* Adds the "initrd=start,size" command line parameter to command line. */ > +static void cmdline_add_initrd(struct kimage *image, unsigned long *cmdline_tmplen, > + char *modified_cmdline, unsigned long initrd) > +{ > + int initrd_strlen; > + > + initrd_strlen = sprintf(modified_cmdline + (*cmdline_tmplen), "initrd=0x%lx,0x%lx ", modified_cmdline is allocated as COMMAND_LINE_SIZE bytes, thus I think it's possible to overflow the buffer. > + initrd, image->initrd_buf_len); > + *cmdline_tmplen += initrd_strlen; > +} > + > +/* > + * Tries to add the initrd to the image. If it is not possible to find > + * valid locations, this function will undo changes to the image and return non > + * zero. > + */ > int load_other_segments(struct kimage *image, > unsigned long kernel_load_addr, > unsigned long kernel_size, > char *initrd, unsigned long initrd_len, > char *cmdline, unsigned long cmdline_len) > { > + struct kexec_buf kbuf; > + unsigned long orig_segments = image->nr_segments; > + char *modified_cmdline = NULL; > + unsigned long cmdline_tmplen = 0; > + unsigned long initrd_load_addr = 0; > + int ret = 0; > + > + > + kbuf.image = image; > + /* not allocate anything below the kernel */ > + kbuf.buf_min = kernel_load_addr + kernel_size; > + > + modified_cmdline = kzalloc(COMMAND_LINE_SIZE, GFP_KERNEL); > + if (!modified_cmdline) > + return -EINVAL; > + > + /* Ensure it's nul terminated */ > + modified_cmdline[COMMAND_LINE_SIZE - 1] = '\0'; > + > + /* load initrd */ > + if (initrd) { > + kbuf.buffer = initrd; > + kbuf.bufsz = initrd_len; > + kbuf.mem = KEXEC_BUF_MEM_UNKNOWN; > + kbuf.memsz = initrd_len; > + kbuf.buf_align = 0; > + /* within 1GB-aligned window of up to 32GB in size */ > + kbuf.buf_max = round_down(kernel_load_addr, 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; > + > + kexec_dprintk("Loaded initrd at 0x%lx bufsz=0x%lx memsz=0x%lx\n", > + initrd_load_addr, kbuf.bufsz, kbuf.memsz); > + > + /* Add the initrd=start,size parameter to the command line */ > + cmdline_add_initrd(image, &cmdline_tmplen, modified_cmdline, initrd_load_addr); > + } > + > + if (cmdline_len + cmdline_tmplen > COMMAND_LINE_SIZE) { It's too later to check for overflowing here, where the data after modified_cmdline may already be overwritten. > + pr_err("Appending kdump cmdline exceeds cmdline size\n"); I think load_other_segments could be invoked without kdump involved. If that's correct, this message is inaccurate. > + ret = -EINVAL; > + goto out_err; > + } Regards, Yao Zi > + memcpy(modified_cmdline + cmdline_tmplen, cmdline, cmdline_len); > + cmdline = modified_cmdline; > image->arch.cmdline_ptr = (unsigned long)cmdline; > > return 0; > + > +out_err: > + image->nr_segments = orig_segments; > + kfree(modified_cmdline); > + return ret; > } > -- > 2.34.1 > >