Received: by 2002:a05:6358:c692:b0:131:369:b2a3 with SMTP id fe18csp2677414rwb; Sat, 29 Jul 2023 11:25:08 -0700 (PDT) X-Google-Smtp-Source: APBJJlHDVQI3oqZNRGsZj7dv+Djq0S5QZbARWcwR2rPkYism7POlIFm303IXW0NO9LA86ZZs6Hjs X-Received: by 2002:aa7:d74f:0:b0:522:2ba9:6fce with SMTP id a15-20020aa7d74f000000b005222ba96fcemr6115547eds.8.1690655107851; Sat, 29 Jul 2023 11:25:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690655107; cv=none; d=google.com; s=arc-20160816; b=qUA/JFcX8ISwvSD3BgOxrdDVB/ydqwtobIvCUImoAneYj/BP19iQByT4PwHjYYPQ+P sPploamdqY8ZBHckQEC6BOcBY+KWR39mfp8wQ0f57gP97Cp5mdAEih9ddjwyODDo4Xip s4SyDd1Pt7XjDN+6IRXqO2igJ2NZd7dushWMrbsIrhTGPc72n2KD1aX8fSObiY75Iqct G1ib7Rohq43KsooIkkvFmT50Wc2D++sBPzUf5OkzNVE13xEjENoa8fXnctoc+fvjA6LF ZKCQTUQKrts30LNj6IA2FK5cyJSAG4xahkWpw+8gCEsgX3U0xvQvCMj+ClWiJzrRAnkF fInw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=5E04Q09jkSKLBlUDV+TBMLLhfegxZryTgGsAr0lByko=; fh=0TI97mHahaZ2FemGl7/S9CmoQ4oZMmJPwx+tCdU+xS8=; b=HKLXBBqz62slzRZf/FuooofCs5WzeqH9yAZYvLM9KrtL3VvH9gMUnrGgBIMq8TVRj9 0eO0807mVeDnPm7WM+e//FwD71lj2uf7ZnppR1xhxcK3fQOAJAQE6JH71ShBM7xC+CU6 XLAIvHWubt9+KtTIGb6XHd1v+cBPZ2CLijXjXrSxMbB7vAwXwIbcW+Ar1dFlnTLpw73v mxvVMaTc3tD5ZeYpt/K42oAoDvop+JoEQGslEwDYelrKuHQxcB5QBZfZbjV6iPegsWG5 6ngrVVd24dm7vu0rCYwn7nxTp5eZuiQRK0x7737qJDNVsvgCTQrOJv2uBVVTsYeL5GJp u4OA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RLnqJ0k5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l16-20020aa7d950000000b00522270c5923si4415412eds.528.2023.07.29.11.24.43; Sat, 29 Jul 2023 11:25:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RLnqJ0k5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229554AbjG2QRD (ORCPT + 99 others); Sat, 29 Jul 2023 12:17:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229379AbjG2QRC (ORCPT ); Sat, 29 Jul 2023 12:17:02 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 271C53A9A; Sat, 29 Jul 2023 09:16:58 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B0E0E60C74; Sat, 29 Jul 2023 16:16:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13DAEC433C8; Sat, 29 Jul 2023 16:16:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690647417; bh=InmMnv82Rb71xb8zyMPM4nJMbzQ42zImCNwr0AM1EgM=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=RLnqJ0k57tZQFunzQJ770LJ6PbAKFSofjfK7SA6x407j1xulxy8mEiyq6vAjPR/qA V8BlvU0gEBwkHyF/7TVLPTdjpdXFaqsxqvfBznNzEwFRJ/jq79NCha8O/cd7l6WCIe aWO2vRN3iJK82RUShi4q+vt7tM0vqpsr5oqRSDqEloDvCcoJhmyHc45chN944HetiQ WtzEQcS6Q1LtPp8nC2R5fbbwQyG3HMWjIi4YJ197f97tEHqi6urXQtqVmfv+P26KWA tiQw4VgbyIioJqGOP92FdU2ZhA8Xl6M6aztqK3cDdsoy8lXJlnigqzxbCd5lv9XY8R JXP/xZThod3XA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 970DACE0A10; Sat, 29 Jul 2023 09:16:56 -0700 (PDT) Date: Sat, 29 Jul 2023 09:16:56 -0700 From: "Paul E. McKenney" To: Masami Hiramatsu Cc: akpm@linux-foundation.org, adobriyan@gmail.com, arnd@kernel.org, ndesaulniers@google.com, sfr@canb.auug.org.au, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH RFC bootconfig] 1/2] fs/proc: Add /proc/cmdline_load for boot loader arguments Message-ID: Reply-To: paulmck@kernel.org References: <197cba95-3989-4d2f-a9f1-8b192ad08c49@paulmck-laptop> <20230728033701.817094-1-paulmck@kernel.org> <20230729232929.a3e962f46c16973031bb466c@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230729232929.a3e962f46c16973031bb466c@kernel.org> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 29, 2023 at 11:29:29PM +0900, Masami Hiramatsu wrote: > Hi Paul, > > On Thu, 27 Jul 2023 20:37:00 -0700 > "Paul E. McKenney" wrote: > > > In kernels built with CONFIG_BOOT_CONFIG_FORCE=y, /proc/cmdline will > > show all kernel boot parameters, both those supplied by the boot loader > > and those embedded in the kernel image. This works well for those who > > just want to see all of the kernel boot parameters, but is not helpful to > > those who need to see only those parameters supplied by the boot loader. > > This is especially important when these parameters are presented to the > > boot loader by automation that might gather them from diverse sources. > > > > Therefore, provide a /proc/cmdline_load file that shows only those kernel > > boot parameters supplied by the boot loader. > > If I understand correctly, /proc/cmdline_load is something like > /proc/cmdline_load - `/proc/bootconfig | grep ^kernel\\.`. Yes, very much something like that. For one use case, suppose you have a kernel that gets some boot parameters from the boot loader and some from bootconfig. If you want to kexec() into a new kernel, you must tell kexec() what the kernel boot parameters are. However, you must *not* tell kexec() about any of the current kernel's parameters that came from bootconfig, because those should instead be supplied by the new kernel being kexec()ed into. So you must pass in only those parameters that came from the boot loader, hence my proposed /proc/cmdline_load. > BTW, what about CONFIG_CMDLINE? We already have that Kconfig and it is also > merged with the command line specified by boot loader. Should we also > expose that? (when CONFIG_CMDLINE_OVERRIDE=y, we don't need it because > cmdline is always overridden by the CONFIG_CMDLINE) Unfortunatelly, this > option is implemented in each arch init, so we have to change all of them... The use case is embedded systems, right? I have no idea whether they have a use case requiring this. Do those sorts of embedded systems use kexec()? (I don't know of any that do, but then again, I haven't been looking.) This arch init is in setup_arch(), correct? If so, one option is to make start_kernel() or something that it invokes make a copy of the command line just before invoking setup_arch(). Full disclosure: I have not yet looked at all the ins and outs of CONFIG_CMDLINE, so this suggestion should be viewed with appropriate skepticism. > Thank you, > > > > > Why put this in /proc? Because it is quite similar to /proc/cmdline, so > > it makes sense to put it in the same place that /proc/cmdline is located. > > > > [ sfr: Apply kernel test robot feedback. ] > > > > Co-developed-by: Stephen Rothwell > > Signed-off-by: Stephen Rothwell > > Co-developed-by: Arnd Bergmann > > Signed-off-by: Arnd Bergmann > > Signed-off-by: Paul E. McKenney > > Reviewed-by: Nick Desaulniers > > Cc: Andrew Morton > > Cc: Alexey Dobriyan > > Cc: Masami Hiramatsu > > Cc: > > --- > > fs/proc/cmdline.c | 13 +++++++++++++ > > include/linux/init.h | 3 ++- > > init/main.c | 2 +- > > 3 files changed, 16 insertions(+), 2 deletions(-) > > > > diff --git a/fs/proc/cmdline.c b/fs/proc/cmdline.c > > index a6f76121955f..1d0ef9d2949d 100644 > > --- a/fs/proc/cmdline.c > > +++ b/fs/proc/cmdline.c > > @@ -3,6 +3,7 @@ > > #include > > #include > > #include > > +#include > > #include "internal.h" > > > > static int cmdline_proc_show(struct seq_file *m, void *v) > > @@ -12,6 +13,13 @@ static int cmdline_proc_show(struct seq_file *m, void *v) > > return 0; > > } > > > > +static int cmdline_load_proc_show(struct seq_file *m, void *v) > > +{ > > + seq_puts(m, boot_command_line); > > + seq_putc(m, '\n'); > > + return 0; > > +} > > + > > static int __init proc_cmdline_init(void) > > { > > struct proc_dir_entry *pde; > > @@ -19,6 +27,11 @@ static int __init proc_cmdline_init(void) > > pde = proc_create_single("cmdline", 0, NULL, cmdline_proc_show); > > pde_make_permanent(pde); > > pde->size = saved_command_line_len + 1; > > + if (IS_ENABLED(CONFIG_BOOT_CONFIG_FORCE)) { > > + pde = proc_create_single("cmdline_load", 0, NULL, cmdline_load_proc_show); > > + pde_make_permanent(pde); > > + pde->size = strnlen(boot_command_line, COMMAND_LINE_SIZE) + 1; > > + } > > return 0; > > } > > fs_initcall(proc_cmdline_init); > > diff --git a/include/linux/init.h b/include/linux/init.h > > index 266c3e1640d4..29e75bbe7984 100644 > > --- a/include/linux/init.h > > +++ b/include/linux/init.h > > @@ -112,6 +112,7 @@ > > #define __REFCONST .section ".ref.rodata", "a" > > > > #ifndef __ASSEMBLY__ > > + > > /* > > * Used for initialization calls.. > > */ > > @@ -143,7 +144,7 @@ struct file_system_type; > > > > /* Defined in init/main.c */ > > extern int do_one_initcall(initcall_t fn); > > -extern char __initdata boot_command_line[]; > > +extern char boot_command_line[]; > > FYI, boot_command_line[] is mixture of built-in cmdline string with > bootloader cmdline string. So if we also need to separate out the CONFIG_CMDLINE arguments, then /proc/cmdline_load will need to come from some string saved off before the CONFIG_CMDLINE processing, correct? I would expect that to be a separate patch series, but if it is needed, I would be happy to look into setting it up, as long as I am in the area. My tests indicate that boot_command_line[] doesn't contain any bootconfig (and opposed to CONFIG_CMDLINE) arguments, but I could easily have missed some other corner-case configuration. And thank you for looking this over! Thanx, Paul > > extern char *saved_command_line; > > extern unsigned int saved_command_line_len; > > extern unsigned int reset_devices; > > diff --git a/init/main.c b/init/main.c > > index ad920fac325c..2121685c479a 100644 > > --- a/init/main.c > > +++ b/init/main.c > > @@ -135,7 +135,7 @@ EXPORT_SYMBOL(system_state); > > void (*__initdata late_time_init)(void); > > > > /* Untouched command line saved by arch-specific code. */ > > -char __initdata boot_command_line[COMMAND_LINE_SIZE]; > > +char boot_command_line[COMMAND_LINE_SIZE] __ro_after_init; > > /* Untouched saved command line (eg. for /proc) */ > > char *saved_command_line __ro_after_init; > > unsigned int saved_command_line_len __ro_after_init; > > -- > > 2.40.1 > > > > > -- > Masami Hiramatsu (Google)