[PATCH v2 0/3] support setting sysctl parameters from kernel command line

[PATCH v2 0/3] support setting sysctl parameters from kernel command line

[Vlastimil Babka]

This series adds support for something that seems like many people always
wanted but nobody added it yet, so here's the ability to set sysctl parameters
via kernel command line options in the form of sysctl.vm.something=1

The important part is Patch 1. The second, not so important part is an attempt
to clean up legacy one-off parameters that do the same thing as a sysctl.
I don't want to remove them completely for compatibility reasons, but with
generic sysctl support the idea is to remove the one-off param handlers and
treat the parameters as aliases for the sysctl variants.

I have identified several parameters that mention sysctl counterparts in
Documentation/admin-guide/kernel-parameters.txt but there might be more. The
conversion also has varying level of success:

- numa_zonelist_order is converted in Patch 2 together with adding the
  necessary infrastructure. It's easy as it doesn't really do anything but warn
  on deprecated value these days.
- hung_task_panic is converted in Patch 3, but there's a downside that now it
  only accepts 0 and 1, while previously it was any integer value
- nmi_watchdog maps to two sysctls nmi_watchdog and hardlockup_panic, so
  there's no straighforward conversion possible
- traceoff_on_warning is a flag without value and it would be required to
  handle that somehow in the conversion infractructure, which seems pointless
  for a single flag

Vlastimil Babka (3):
  kernel/sysctl: support setting sysctl parameters from kernel command
    line
  kernel/sysctl: support handling command line aliases
  kernel/hung_task convert hung_task_panic boot parameter to sysctl

Changes since v1:
- add missing newlines on printk's
- more adjustments to proc mount param passing (Kees)
- rebase to 5.7-rc1
- add acks/reviews
- test driver (how to pass a testing boot parameter without bootloader specific
  steps) still under discussion - new Kconfig? bootconfig?

 .../admin-guide/kernel-parameters.txt         |  11 +-
 fs/proc/proc_sysctl.c                         | 142 ++++++++++++++++++
 include/linux/sysctl.h                        |   4 +
 init/main.c                                   |   2 +
 kernel/hung_task.c                            |  10 --
 mm/page_alloc.c                               |   9 --
 6 files changed, 158 insertions(+), 20 deletions(-)

-- 
2.26.0

[PATCH v2 1/3] kernel/sysctl: support setting sysctl parameters from kernel command line

[Vlastimil Babka]

A recently proposed patch to add vm_swappiness command line parameter in
addition to existing sysctl [1] made me wonder why we don't have a general
support for passing sysctl parameters via command line. Googling found only
somebody else wondering the same [2], but I haven't found any prior discussion
with reasons why not to do this.

Settings the vm_swappiness issue aside (the underlying issue might be solved in
a different way), quick search of kernel-parameters.txt shows there are already
some that exist as both sysctl and kernel parameter - hung_task_panic,
nmi_watchdog, numa_zonelist_order, traceoff_on_warning. A general mechanism
would remove the need to add more of those one-offs and might be handy in
situations where configuration by e.g. /etc/sysctl.d/ is impractical.

Hence, this patch adds a new parse_args() pass that looks for parameters
prefixed by 'sysctl.' and tries to interpret them as writes to the
corresponding sys/ files using an temporary in-kernel procfs mount. This
mechanism was suggested by Eric W. Biederman [3], as it handles all dynamically
registered sysctl tables, even though we don't handle modular sysctls. Errors
due to e.g. invalid parameter name or value are reported in the kernel log.

The processing is hooked right before the init process is loaded, as some
handlers might be more complicated than simple setters and might need some
subsystems to be initialized. At the moment the init process can be started and
eventually execute a process writing to /proc/sys/ then it should be also fine
to do that from the kernel.

Sysctls registered later on module load time are not set by this mechanism -
it's expected that in such scenarios, setting sysctl values from userspace is
practical enough.

[1] https://lore.kernel.org/r/BL0PR02MB560167492CA4094C91589930E9FC0@BL0PR02MB5601.namprd02.prod.outlook.com/
[2] https://unix.stackexchange.com/questions/558802/how-to-set-sysctl-using-kernel-command-line-parameter
[3] https://lore.kernel.org/r/87bloj2skm.fsf@x220.int.ebiederm.org/

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
---
 .../admin-guide/kernel-parameters.txt         |   9 ++
 fs/proc/proc_sysctl.c                         | 107 ++++++++++++++++++
 include/linux/sysctl.h                        |   4 +
 init/main.c                                   |   2 +
 4 files changed, 122 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f2a93c8679e8..fd38f1e8a2bf 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4891,6 +4891,15 @@
 
 	switches=	[HW,M68k]
 
+	sysctl.*=	[KNL]
+			Set a sysctl parameter, right before loading the init
+			process, as if the value was written to the respective
+			/proc/sys/... file. Both '.' and '/' are recognized as
+			separators. Unrecognized parameters and invalid values
+			are reported in the kernel log. Sysctls registered
+			later by a loaded module cannot be set this way.
+			Example: sysctl.vm.swappiness=40
+
 	sysfs.deprecated=0|1 [KNL]
 			Enable/disable old style sysfs layout for old udev
 			on older distributions. When this option is enabled
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index b6f5d459b087..7804da5f5be0 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -14,6 +14,7 @@
 #include <linux/mm.h>
 #include <linux/module.h>
 #include <linux/bpf-cgroup.h>
+#include <linux/mount.h>
 #include "internal.h"
 
 static const struct dentry_operations proc_sys_dentry_operations;
@@ -1692,3 +1693,109 @@ int __init proc_sys_init(void)
 
 	return sysctl_init();
 }
+
+/* Set sysctl value passed on kernel command line. */
+static int process_sysctl_arg(char *param, char *val,
+			       const char *unused, void *arg)
+{
+	char *path;
+	struct vfsmount **proc_mnt = arg;
+	struct file_system_type *proc_fs_type;
+	struct file *file;
+	int len;
+	int err;
+	loff_t pos = 0;
+	ssize_t wret;
+
+	if (strncmp(param, "sysctl", sizeof("sysctl") - 1))
+		return 0;
+
+	param += sizeof("sysctl") - 1;
+
+	if (param[0] != '/' && param[0] != '.')
+		return 0;
+
+	param++;
+
+	/*
+	 * To set sysctl options, we use a temporary mount of proc, look up the
+	 * respective sys/ file and write to it. To avoid mounting it when no
+	 * options were given, we mount it only when the first sysctl option is
+	 * found. Why not a persistent mount? There are problems with a
+	 * persistent mount of proc in that it forces userspace not to use any
+	 * proc mount options.
+	 */
+	if (!*proc_mnt) {
+		proc_fs_type = get_fs_type("proc");
+		if (!proc_fs_type) {
+			pr_err("Failed to find procfs to set sysctl from command line\n");
+			return 0;
+		}
+		*proc_mnt = kern_mount(proc_fs_type);
+		put_filesystem(proc_fs_type);
+		if (IS_ERR(*proc_mnt)) {
+			pr_err("Failed to mount procfs to set sysctl from command line\n");
+			return 0;
+		}
+	}
+
+	path = kasprintf(GFP_KERNEL, "sys/%s", param);
+	if (!path)
+		panic("%s: Failed to allocate path for %s\n", __func__, param);
+	strreplace(path, '.', '/');
+
+	file = file_open_root((*proc_mnt)->mnt_root, *proc_mnt, path, O_WRONLY, 0);
+	if (IS_ERR(file)) {
+		err = PTR_ERR(file);
+		if (err == -ENOENT)
+			pr_err("Failed to set sysctl parameter '%s=%s': parameter not found\n",
+				param, val);
+		else if (err == -EACCES)
+			pr_err("Failed to set sysctl parameter '%s=%s': permission denied (read-only?)\n",
+				param, val);
+		else
+			pr_err("Error %pe opening proc file to set sysctl parameter '%s=%s'\n",
+				file, param, val);
+		goto out;
+	}
+	len = strlen(val);
+	wret = kernel_write(file, val, len, &pos);
+	if (wret < 0) {
+		err = wret;
+		if (err == -EINVAL)
+			pr_err("Failed to set sysctl parameter '%s=%s': invalid value\n",
+				param, val);
+		else
+			pr_err("Error %pe writing to proc file to set sysctl parameter '%s=%s'\n",
+				ERR_PTR(err), param, val);
+	} else if (wret != len) {
+		pr_err("Wrote only %zd bytes of %d writing to proc file %s to set sysctl parameter '%s=%s\n",
+			wret, len, path, param, val);
+	}
+
+	err = filp_close(file, NULL);
+	if (err)
+		pr_err("Error %pe closing proc file to set sysctl parameter '%s=%s\n",
+			ERR_PTR(err), param, val);
+out:
+	kfree(path);
+	return 0;
+}
+
+void do_sysctl_args(void)
+{
+	char *command_line;
+	struct vfsmount *proc_mnt = NULL;
+
+	command_line = kstrdup(saved_command_line, GFP_KERNEL);
+	if (!command_line)
+		panic("%s: Failed to allocate copy of command line\n", __func__);
+
+	parse_args("Setting sysctl args", command_line,
+		   NULL, 0, -1, -1, &proc_mnt, process_sysctl_arg);
+
+	if (proc_mnt)
+		kern_unmount(proc_mnt);
+
+	kfree(command_line);
+}
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 02fa84493f23..bee62d30ebdb 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -206,6 +206,7 @@ struct ctl_table_header *register_sysctl_paths(const struct ctl_path *path,
 void unregister_sysctl_table(struct ctl_table_header * table);
 
 extern int sysctl_init(void);
+void do_sysctl_args(void);
 
 extern struct ctl_table sysctl_mount_point[];
 
@@ -236,6 +237,9 @@ static inline void setup_sysctl_set(struct ctl_table_set *p,
 {
 }
 
+static inline void do_sysctl_args(void)
+{
+}
 #endif /* CONFIG_SYSCTL */
 
 int sysctl_max_threads(struct ctl_table *table, int write,
diff --git a/init/main.c b/init/main.c
index a48617f2e5e5..7b43118215d6 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1372,6 +1372,8 @@ static int __ref kernel_init(void *unused)
 
 	rcu_end_inkernel_boot();
 
+	do_sysctl_args();
+
 	if (ramdisk_execute_command) {
 		ret = run_init_process(ramdisk_execute_command);
 		if (!ret)
-- 
2.26.0

[PATCH v2 2/3] kernel/sysctl: support handling command line aliases

[Vlastimil Babka]

We can now handle sysctl parameters on kernel command line, but historically
some parameters introduced their own command line equivalent, which we don't
want to remove for compatibility reasons. We can however convert them to the
generic infrastructure with a table translating the legacy command line
parameters to their sysctl names, and removing the one-off param handlers.

This patch adds the support and makes the first conversion to demonstrate it,
on the (deprecated) numa_zonelist_order parameter.

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
---
 fs/proc/proc_sysctl.c | 48 ++++++++++++++++++++++++++++++++++++-------
 mm/page_alloc.c       |  9 --------
 2 files changed, 41 insertions(+), 16 deletions(-)

diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index 7804da5f5be0..209ad03e1b82 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -1694,6 +1694,37 @@ int __init proc_sys_init(void)
 	return sysctl_init();
 }
 
+struct sysctl_alias {
+	const char *kernel_param;
+	const char *sysctl_param;
+};
+
+/*
+ * Historically some settings had both sysctl and a command line parameter.
+ * With the generic sysctl. parameter support, we can handle them at a single
+ * place and only keep the historical name for compatibility. This is not meant
+ * to add brand new aliases. When adding existing aliases, consider whether
+ * the possibly different moment of changing the value (e.g. from early_param
+ * to the moment do_sysctl_args() is called) is an issue for the specific
+ * parameter.
+ */
+static const struct sysctl_alias sysctl_aliases[] = {
+	{"numa_zonelist_order",		"vm.numa_zonelist_order" },
+	{ }
+};
+
+static const char *sysctl_find_alias(char *param)
+{
+	const struct sysctl_alias *alias;
+
+	for (alias = &sysctl_aliases[0]; alias->kernel_param != NULL; alias++) {
+		if (strcmp(alias->kernel_param, param) == 0)
+			return alias->sysctl_param;
+	}
+
+	return NULL;
+}
+
 /* Set sysctl value passed on kernel command line. */
 static int process_sysctl_arg(char *param, char *val,
 			       const char *unused, void *arg)
@@ -1707,15 +1738,18 @@ static int process_sysctl_arg(char *param, char *val,
 	loff_t pos = 0;
 	ssize_t wret;
 
-	if (strncmp(param, "sysctl", sizeof("sysctl") - 1))
-		return 0;
-
-	param += sizeof("sysctl") - 1;
+	if (strncmp(param, "sysctl", sizeof("sysctl") - 1) == 0) {
+		param += sizeof("sysctl") - 1;
 
-	if (param[0] != '/' && param[0] != '.')
-		return 0;
+		if (param[0] != '/' && param[0] != '.')
+			return 0;
 
-	param++;
+		param++;
+	} else {
+		param = (char *) sysctl_find_alias(param);
+		if (!param)
+			return 0;
+	}
 
 	/*
 	 * To set sysctl options, we use a temporary mount of proc, look up the
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 69827d4fa052..80b2788711c9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5531,15 +5531,6 @@ static int __parse_numa_zonelist_order(char *s)
 	return 0;
 }
 
-static __init int setup_numa_zonelist_order(char *s)
-{
-	if (!s)
-		return 0;
-
-	return __parse_numa_zonelist_order(s);
-}
-early_param("numa_zonelist_order", setup_numa_zonelist_order);
-
 char numa_zonelist_order[] = "Node";
 
 /*
-- 
2.26.0

[PATCH v2 3/3] kernel/hung_task convert hung_task_panic boot parameter to sysctl

[Vlastimil Babka]

We can now handle sysctl parameters on kernel command line and have
infrastructure to convert legacy command line options that duplicate sysctl
to become a sysctl alias.

This patch converts the hung_task_panic parameter. Note that the sysctl handler
is more strict and allows only 0 and 1, while the legacy parameter allowed
any non-zero value. But there is little reason anyone would not be using 1.

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Kees Cook <keescook@chromium.org>
---
 Documentation/admin-guide/kernel-parameters.txt |  2 +-
 fs/proc/proc_sysctl.c                           |  1 +
 kernel/hung_task.c                              | 10 ----------
 3 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index fd38f1e8a2bf..e60478d9d377 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1491,7 +1491,7 @@
 			[KNL] Should the hung task detector generate panics.
 			Format: <integer>
 
-			A nonzero value instructs the kernel to panic when a
+			A value of 1 instructs the kernel to panic when a
 			hung task is detected. The default value is controlled
 			by the CONFIG_BOOTPARAM_HUNG_TASK_PANIC build-time
 			option. The value selected by this boot parameter can
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index 209ad03e1b82..e8f97bd65909 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -1710,6 +1710,7 @@ struct sysctl_alias {
  */
 static const struct sysctl_alias sysctl_aliases[] = {
 	{"numa_zonelist_order",		"vm.numa_zonelist_order" },
+	{"hung_task_panic",		"kernel.hung_task_panic" },
 	{ }
 };
 
diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index 14a625c16cb3..b22b5eeab3cb 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -63,16 +63,6 @@ static struct task_struct *watchdog_task;
 unsigned int __read_mostly sysctl_hung_task_panic =
 				CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE;
 
-static int __init hung_task_panic_setup(char *str)
-{
-	int rc = kstrtouint(str, 0, &sysctl_hung_task_panic);
-
-	if (rc)
-		return rc;
-	return 1;
-}
-__setup("hung_task_panic=", hung_task_panic_setup);
-
 static int
 hung_task_panic(struct notifier_block *this, unsigned long event, void *ptr)
 {
-- 
2.26.0

Re: [PATCH v2 1/3] kernel/sysctl: support setting sysctl parameters from kernel command line

[Kees Cook]

On Tue, Apr 14, 2020 at 01:32:20PM +0200, Vlastimil Babka wrote:
> A recently proposed patch to add vm_swappiness command line parameter in
> addition to existing sysctl [1] made me wonder why we don't have a general
> support for passing sysctl parameters via command line. Googling found only
> somebody else wondering the same [2], but I haven't found any prior discussion
> with reasons why not to do this.
> 
> Settings the vm_swappiness issue aside (the underlying issue might be solved in
> a different way), quick search of kernel-parameters.txt shows there are already
> some that exist as both sysctl and kernel parameter - hung_task_panic,
> nmi_watchdog, numa_zonelist_order, traceoff_on_warning. A general mechanism
> would remove the need to add more of those one-offs and might be handy in
> situations where configuration by e.g. /etc/sysctl.d/ is impractical.
> 
> Hence, this patch adds a new parse_args() pass that looks for parameters
> prefixed by 'sysctl.' and tries to interpret them as writes to the
> corresponding sys/ files using an temporary in-kernel procfs mount. This
> mechanism was suggested by Eric W. Biederman [3], as it handles all dynamically
> registered sysctl tables, even though we don't handle modular sysctls. Errors
> due to e.g. invalid parameter name or value are reported in the kernel log.
> 
> The processing is hooked right before the init process is loaded, as some
> handlers might be more complicated than simple setters and might need some
> subsystems to be initialized. At the moment the init process can be started and
> eventually execute a process writing to /proc/sys/ then it should be also fine
> to do that from the kernel.
> 
> Sysctls registered later on module load time are not set by this mechanism -
> it's expected that in such scenarios, setting sysctl values from userspace is
> practical enough.
> 
> [1] https://lore.kernel.org/r/BL0PR02MB560167492CA4094C91589930E9FC0@BL0PR02MB5601.namprd02.prod.outlook.com/
> [2] https://unix.stackexchange.com/questions/558802/how-to-set-sysctl-using-kernel-command-line-parameter
> [3] https://lore.kernel.org/r/87bloj2skm.fsf@x220.int.ebiederm.org/
> 
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>

Looks great!

Acked-by: Kees Cook <keescook@chromium.org>

-Kees

> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
> ---
>  .../admin-guide/kernel-parameters.txt         |   9 ++
>  fs/proc/proc_sysctl.c                         | 107 ++++++++++++++++++
>  include/linux/sysctl.h                        |   4 +
>  init/main.c                                   |   2 +
>  4 files changed, 122 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index f2a93c8679e8..fd38f1e8a2bf 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4891,6 +4891,15 @@
>  
>  	switches=	[HW,M68k]
>  
> +	sysctl.*=	[KNL]
> +			Set a sysctl parameter, right before loading the init
> +			process, as if the value was written to the respective
> +			/proc/sys/... file. Both '.' and '/' are recognized as
> +			separators. Unrecognized parameters and invalid values
> +			are reported in the kernel log. Sysctls registered
> +			later by a loaded module cannot be set this way.
> +			Example: sysctl.vm.swappiness=40
> +
>  	sysfs.deprecated=0|1 [KNL]
>  			Enable/disable old style sysfs layout for old udev
>  			on older distributions. When this option is enabled
> diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
> index b6f5d459b087..7804da5f5be0 100644
> --- a/fs/proc/proc_sysctl.c
> +++ b/fs/proc/proc_sysctl.c
> @@ -14,6 +14,7 @@
>  #include <linux/mm.h>
>  #include <linux/module.h>
>  #include <linux/bpf-cgroup.h>
> +#include <linux/mount.h>
>  #include "internal.h"
>  
>  static const struct dentry_operations proc_sys_dentry_operations;
> @@ -1692,3 +1693,109 @@ int __init proc_sys_init(void)
>  
>  	return sysctl_init();
>  }
> +
> +/* Set sysctl value passed on kernel command line. */
> +static int process_sysctl_arg(char *param, char *val,
> +			       const char *unused, void *arg)
> +{
> +	char *path;
> +	struct vfsmount **proc_mnt = arg;
> +	struct file_system_type *proc_fs_type;
> +	struct file *file;
> +	int len;
> +	int err;
> +	loff_t pos = 0;
> +	ssize_t wret;
> +
> +	if (strncmp(param, "sysctl", sizeof("sysctl") - 1))
> +		return 0;
> +
> +	param += sizeof("sysctl") - 1;
> +
> +	if (param[0] != '/' && param[0] != '.')
> +		return 0;
> +
> +	param++;
> +
> +	/*
> +	 * To set sysctl options, we use a temporary mount of proc, look up the
> +	 * respective sys/ file and write to it. To avoid mounting it when no
> +	 * options were given, we mount it only when the first sysctl option is
> +	 * found. Why not a persistent mount? There are problems with a
> +	 * persistent mount of proc in that it forces userspace not to use any
> +	 * proc mount options.
> +	 */
> +	if (!*proc_mnt) {
> +		proc_fs_type = get_fs_type("proc");
> +		if (!proc_fs_type) {
> +			pr_err("Failed to find procfs to set sysctl from command line\n");
> +			return 0;
> +		}
> +		*proc_mnt = kern_mount(proc_fs_type);
> +		put_filesystem(proc_fs_type);
> +		if (IS_ERR(*proc_mnt)) {
> +			pr_err("Failed to mount procfs to set sysctl from command line\n");
> +			return 0;
> +		}
> +	}
> +
> +	path = kasprintf(GFP_KERNEL, "sys/%s", param);
> +	if (!path)
> +		panic("%s: Failed to allocate path for %s\n", __func__, param);
> +	strreplace(path, '.', '/');
> +
> +	file = file_open_root((*proc_mnt)->mnt_root, *proc_mnt, path, O_WRONLY, 0);
> +	if (IS_ERR(file)) {
> +		err = PTR_ERR(file);
> +		if (err == -ENOENT)
> +			pr_err("Failed to set sysctl parameter '%s=%s': parameter not found\n",
> +				param, val);
> +		else if (err == -EACCES)
> +			pr_err("Failed to set sysctl parameter '%s=%s': permission denied (read-only?)\n",
> +				param, val);
> +		else
> +			pr_err("Error %pe opening proc file to set sysctl parameter '%s=%s'\n",
> +				file, param, val);
> +		goto out;
> +	}
> +	len = strlen(val);
> +	wret = kernel_write(file, val, len, &pos);
> +	if (wret < 0) {
> +		err = wret;
> +		if (err == -EINVAL)
> +			pr_err("Failed to set sysctl parameter '%s=%s': invalid value\n",
> +				param, val);
> +		else
> +			pr_err("Error %pe writing to proc file to set sysctl parameter '%s=%s'\n",
> +				ERR_PTR(err), param, val);
> +	} else if (wret != len) {
> +		pr_err("Wrote only %zd bytes of %d writing to proc file %s to set sysctl parameter '%s=%s\n",
> +			wret, len, path, param, val);
> +	}
> +
> +	err = filp_close(file, NULL);
> +	if (err)
> +		pr_err("Error %pe closing proc file to set sysctl parameter '%s=%s\n",
> +			ERR_PTR(err), param, val);
> +out:
> +	kfree(path);
> +	return 0;
> +}
> +
> +void do_sysctl_args(void)
> +{
> +	char *command_line;
> +	struct vfsmount *proc_mnt = NULL;
> +
> +	command_line = kstrdup(saved_command_line, GFP_KERNEL);
> +	if (!command_line)
> +		panic("%s: Failed to allocate copy of command line\n", __func__);
> +
> +	parse_args("Setting sysctl args", command_line,
> +		   NULL, 0, -1, -1, &proc_mnt, process_sysctl_arg);
> +
> +	if (proc_mnt)
> +		kern_unmount(proc_mnt);
> +
> +	kfree(command_line);
> +}
> diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
> index 02fa84493f23..bee62d30ebdb 100644
> --- a/include/linux/sysctl.h
> +++ b/include/linux/sysctl.h
> @@ -206,6 +206,7 @@ struct ctl_table_header *register_sysctl_paths(const struct ctl_path *path,
>  void unregister_sysctl_table(struct ctl_table_header * table);
>  
>  extern int sysctl_init(void);
> +void do_sysctl_args(void);
>  
>  extern struct ctl_table sysctl_mount_point[];
>  
> @@ -236,6 +237,9 @@ static inline void setup_sysctl_set(struct ctl_table_set *p,
>  {
>  }
>  
> +static inline void do_sysctl_args(void)
> +{
> +}
>  #endif /* CONFIG_SYSCTL */
>  
>  int sysctl_max_threads(struct ctl_table *table, int write,
> diff --git a/init/main.c b/init/main.c
> index a48617f2e5e5..7b43118215d6 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1372,6 +1372,8 @@ static int __ref kernel_init(void *unused)
>  
>  	rcu_end_inkernel_boot();
>  
> +	do_sysctl_args();
> +
>  	if (ramdisk_execute_command) {
>  		ret = run_init_process(ramdisk_execute_command);
>  		if (!ret)
> -- 
> 2.26.0
> 

-- 
Kees Cook

Re: [PATCH v2 0/3] support setting sysctl parameters from kernel command line

[Masami Hiramatsu]

Hi Vlastimil,

On Tue, 14 Apr 2020 13:32:19 +0200
Vlastimil Babka <vbabka@suse.cz> wrote:

> This series adds support for something that seems like many people always
> wanted but nobody added it yet, so here's the ability to set sysctl parameters
> via kernel command line options in the form of sysctl.vm.something=1

Sounds good. And would you consider to use the bootconfig instead of (or
in addition to) the kernel command line, because it is too short to describe
the sysctl options?

With the bootconfig, you can describe the sysctl parameters in an
independent file as same as /etc/sysctl.conf. It is easy to convert
form sysctl.conf to bootconfig because bootconfig format is simply
enhanced structured sysctl.conf :). What we just need is;

(echo "sysctl {"; cat "/etc/sysctl.conf"; echo "}") >> sysctl.bconf
bootconfig -a sysctl.bconf /boot/initrd.img

Even with only your patch, since bootconfig can pass the options which
start with "kernel." prefix to kernel command line, so;

(echo "kernel.sysctl {"; cat "/etc/sysctl.conf"; echo "}") >> sysctl.bconf
bootconfig -a sysctl.bconf /boot/initrd.img

should work. 

Thank you,


-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH v2 0/3] support setting sysctl parameters from kernel command line

[Luis Chamberlain]

On Wed, Apr 15, 2020 at 12:23:59PM +0900, Masami Hiramatsu wrote:
> Hi Vlastimil,
> 
> On Tue, 14 Apr 2020 13:32:19 +0200
> Vlastimil Babka <vbabka@suse.cz> wrote:
> 
> > This series adds support for something that seems like many people always
> > wanted but nobody added it yet, so here's the ability to set sysctl parameters
> > via kernel command line options in the form of sysctl.vm.something=1
> 
> Sounds good. And would you consider to use the bootconfig instead of (or
> in addition to) the kernel command line, because it is too short to describe
> the sysctl options?

FWIW for the lazy:

The cmdline limitation:

Documentation/admin-guide/kernel-parameters.rst

```
The number of kernel parameters is not limited, but the length of the           
complete command line (parameters including spaces etc.) is limited to          
a fixed number of characters. This limit depends on the architecture            
and is between 256 and 4096 characters. It is defined in the file               
./include/asm/setup.h as COMMAND_LINE_SIZE.
```

The bootconfig limitation:

Documentation/admin-guide/bootconfig.rst

```
Currently the maximum config size size is 32KB and the total key-words
(not     key-value entries) must be under 1024 nodes.  Note: this is not
the number of entries but nodes, an entry must consume more than 2 nodes
(a key-word and a value). So theoretically, it will be up to 512
key-value pairs. If keys contains 3 words in average, it can contain 256
key-value pairs. In most cases, the number of config items will be under
100 entries and smaller than 8KB, so it would be enough.  If the node
number exceeds 1024, parser returns an error even if the file       size
is smaller than 32KB.  Anyway, since bootconfig command verifies it when
appending a boot config       to initrd image, user can notice it before
boot.  
```
*recommending* bootconfig due to the limitation of cmdline seems
sensible, however if we advise that.. wouldn't the space for 512
theoretical entries full up rather fast?

  Luis

Re: [PATCH v2 0/3] support setting sysctl parameters from kernel command line

[Vlastimil Babka]

On 4/15/20 5:23 AM, Masami Hiramatsu wrote:
> Hi Vlastimil,
> 
> On Tue, 14 Apr 2020 13:32:19 +0200
> Vlastimil Babka <vbabka@suse.cz> wrote:
> 
>> This series adds support for something that seems like many people always
>> wanted but nobody added it yet, so here's the ability to set sysctl parameters
>> via kernel command line options in the form of sysctl.vm.something=1
> 
> Sounds good. And would you consider to use the bootconfig instead of (or
> in addition to) the kernel command line, because it is too short to describe
> the sysctl options?

"Instead of" - no, as that would defeat the scenario of "I just want to set this
one sysctl in grub  (possibly interactively) and not update initrd for that". If
constructing bootconfig is of similar effort of loading sysctl.conf from initrd,
then I see little benefit?

"in addition to" - sure! but I hoped that's what already happens as it seemed to
me that options from bootconfig are appended to the command line that's then
parsed by everyone else, no? But I'll try it to be sure.

> With the bootconfig, you can describe the sysctl parameters in an
> independent file as same as /etc/sysctl.conf. It is easy to convert
> form sysctl.conf to bootconfig because bootconfig format is simply
> enhanced structured sysctl.conf :). What we just need is;
> 
> (echo "sysctl {"; cat "/etc/sysctl.conf"; echo "}") >> sysctl.bconf
> bootconfig -a sysctl.bconf /boot/initrd.img
> 
> Even with only your patch, since bootconfig can pass the options which
> start with "kernel." prefix to kernel command line, so;
> 
> (echo "kernel.sysctl {"; cat "/etc/sysctl.conf"; echo "}") >> sysctl.bconf
> bootconfig -a sysctl.bconf /boot/initrd.img

Hmm I hope I figure out if the way virtme creates initrd on the fly supports
hooking a bootconfig addition :)

> should work. 
> 
> Thank you,
> 
> 

Re: [PATCH v2 1/3] kernel/sysctl: support setting sysctl parameters from kernel command line

[Masami Hiramatsu]

On Tue, 14 Apr 2020 13:32:20 +0200
Vlastimil Babka <vbabka@suse.cz> wrote:

> A recently proposed patch to add vm_swappiness command line parameter in
> addition to existing sysctl [1] made me wonder why we don't have a general
> support for passing sysctl parameters via command line. Googling found only
> somebody else wondering the same [2], but I haven't found any prior discussion
> with reasons why not to do this.
> 
> Settings the vm_swappiness issue aside (the underlying issue might be solved in
> a different way), quick search of kernel-parameters.txt shows there are already
> some that exist as both sysctl and kernel parameter - hung_task_panic,
> nmi_watchdog, numa_zonelist_order, traceoff_on_warning. A general mechanism
> would remove the need to add more of those one-offs and might be handy in
> situations where configuration by e.g. /etc/sysctl.d/ is impractical.
> 
> Hence, this patch adds a new parse_args() pass that looks for parameters
> prefixed by 'sysctl.' and tries to interpret them as writes to the
> corresponding sys/ files using an temporary in-kernel procfs mount. This
> mechanism was suggested by Eric W. Biederman [3], as it handles all dynamically
> registered sysctl tables, even though we don't handle modular sysctls. Errors
> due to e.g. invalid parameter name or value are reported in the kernel log.
> 
> The processing is hooked right before the init process is loaded, as some
> handlers might be more complicated than simple setters and might need some
> subsystems to be initialized. At the moment the init process can be started and
> eventually execute a process writing to /proc/sys/ then it should be also fine
> to do that from the kernel.
> 
> Sysctls registered later on module load time are not set by this mechanism -
> it's expected that in such scenarios, setting sysctl values from userspace is
> practical enough.
> 
> [1] https://lore.kernel.org/r/BL0PR02MB560167492CA4094C91589930E9FC0@BL0PR02MB5601.namprd02.prod.outlook.com/
> [2] https://unix.stackexchange.com/questions/558802/how-to-set-sysctl-using-kernel-command-line-parameter
> [3] https://lore.kernel.org/r/87bloj2skm.fsf@x220.int.ebiederm.org/
> 
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>

[...]

> diff --git a/init/main.c b/init/main.c
> index a48617f2e5e5..7b43118215d6 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1372,6 +1372,8 @@ static int __ref kernel_init(void *unused)
>  
>  	rcu_end_inkernel_boot();
>  
> +	do_sysctl_args();
> +

Ah, I see. Since the sysctl is designed to be called after all __init calls were
done, it shouldn't use bootconfig directly because bootconfig is full of __init
call. OK, anyway we can use "kernel.sysctl" prefixed bootconfig for these.

Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH v2 0/3] support setting sysctl parameters from kernel command line

[Michal Hocko]

On Wed 15-04-20 10:56:35, Vlastimil Babka wrote:
> On 4/15/20 5:23 AM, Masami Hiramatsu wrote:
> > Hi Vlastimil,
> > 
> > On Tue, 14 Apr 2020 13:32:19 +0200
> > Vlastimil Babka <vbabka@suse.cz> wrote:
> > 
> >> This series adds support for something that seems like many people always
> >> wanted but nobody added it yet, so here's the ability to set sysctl parameters
> >> via kernel command line options in the form of sysctl.vm.something=1
> > 
> > Sounds good. And would you consider to use the bootconfig instead of (or
> > in addition to) the kernel command line, because it is too short to describe
> > the sysctl options?
> 
> "Instead of" - no, as that would defeat the scenario of "I just want to set this
> one sysctl in grub  (possibly interactively) and not update initrd for that". If
> constructing bootconfig is of similar effort of loading sysctl.conf from initrd,
> then I see little benefit?
> 
> "in addition to" - sure! but I hoped that's what already happens as it seemed to
> me that options from bootconfig are appended to the command line that's then
> parsed by everyone else, no? But I'll try it to be sure.

Completely agreed!

Btw. patches look sensible to me so feel free to add
Acked-by: Michal Hocko <mhocko@suse.com>

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 1/3] kernel/sysctl: support setting sysctl parameters from kernel command line

[Luis Chamberlain]

On Wed, Apr 15, 2020 at 06:03:55PM +0900, Masami Hiramatsu wrote:
> On Tue, 14 Apr 2020 13:32:20 +0200
> Vlastimil Babka <vbabka@suse.cz> wrote:
> > diff --git a/init/main.c b/init/main.c
> > index a48617f2e5e5..7b43118215d6 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -1372,6 +1372,8 @@ static int __ref kernel_init(void *unused)
> >  
> >  	rcu_end_inkernel_boot();
> >  
> > +	do_sysctl_args();
> > +
> 
> Ah, I see. Since the sysctl is designed to be called after all __init calls were
> done, it shouldn't use bootconfig directly because bootconfig is full of __init
> call.

The idea is bootconfig would be useful in the sense of a library set of
helpers which could be modified to remove __init, and then used to
instrument the cmdline depending on certain debugging kconfig entries.

We currently have no way to purposely extend / break the cmdline for
debugging purposes, so, bootconfig's parsers, since it already has a
way to extend the cmdlineline, might make it much easier to do this
later.

Without bootconfig, if we wanted to add new kconfig to, for example,
add new funny cmdline arguments to test they worked or not, we'd have
to devise our own set of helpers now. ie, new functionality. bootconfig
however already has existing functionality to tweak the cmdline, and so
some code could be leveraged there for this purpose.

  Luis

Re: [PATCH v2 0/3] support setting sysctl parameters from kernel command line

[Masami Hiramatsu]

Hi Luis,

On Wed, 15 Apr 2020 06:30:41 +0000
Luis Chamberlain <mcgrof@kernel.org> wrote:
> Currently the maximum config size size is 32KB and the total key-words
> (not     key-value entries) must be under 1024 nodes.  Note: this is not
> the number of entries but nodes, an entry must consume more than 2 nodes
> (a key-word and a value). So theoretically, it will be up to 512
> key-value pairs. If keys contains 3 words in average, it can contain 256
> key-value pairs. In most cases, the number of config items will be under
> 100 entries and smaller than 8KB, so it would be enough.  If the node
> number exceeds 1024, parser returns an error even if the file       size
> is smaller than 32KB.  Anyway, since bootconfig command verifies it when
> appending a boot config       to initrd image, user can notice it before
> boot.  
> ```
> *recommending* bootconfig due to the limitation of cmdline seems
> sensible, however if we advise that.. wouldn't the space for 512
> theoretical entries full up rather fast?

Yeah, I think it is easier to hit the node number limitation rather
than fill up the space. However, since the bootconfig supports comments,
if user writes enough readable config file, I think it's probably the
right balance :)
If you think the 512 entries is too small, it is easy to expand it
upto 32K (64K nodes). But it may consume 512KB memory only for the
node (meta) data. Current 1024 nodes consumes 8KB (8bytes/node), so
compared with the max data size (32KB), I think it is a better balance.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH v2 0/3] support setting sysctl parameters from kernel command line

[Masami Hiramatsu]

On Wed, 15 Apr 2020 10:56:35 +0200
Vlastimil Babka <vbabka@suse.cz> wrote:

> On 4/15/20 5:23 AM, Masami Hiramatsu wrote:
> > Hi Vlastimil,
> > 
> > On Tue, 14 Apr 2020 13:32:19 +0200
> > Vlastimil Babka <vbabka@suse.cz> wrote:
> > 
> >> This series adds support for something that seems like many people always
> >> wanted but nobody added it yet, so here's the ability to set sysctl parameters
> >> via kernel command line options in the form of sysctl.vm.something=1
> > 
> > Sounds good. And would you consider to use the bootconfig instead of (or
> > in addition to) the kernel command line, because it is too short to describe
> > the sysctl options?
> 
> "Instead of" - no, as that would defeat the scenario of "I just want to set this
> one sysctl in grub  (possibly interactively) and not update initrd for that". If
> constructing bootconfig is of similar effort of loading sysctl.conf from initrd,
> then I see little benefit?
> 
> "in addition to" - sure! but I hoped that's what already happens as it seemed to
> me that options from bootconfig are appended to the command line that's then
> parsed by everyone else, no? But I'll try it to be sure.

Yes, all configurations under "kernel" key are passed to kernel command line,
so you don't need to change anything :)

> > With the bootconfig, you can describe the sysctl parameters in an
> > independent file as same as /etc/sysctl.conf. It is easy to convert
> > form sysctl.conf to bootconfig because bootconfig format is simply
> > enhanced structured sysctl.conf :). What we just need is;
> > 
> > (echo "sysctl {"; cat "/etc/sysctl.conf"; echo "}") >> sysctl.bconf
> > bootconfig -a sysctl.bconf /boot/initrd.img
> > 
> > Even with only your patch, since bootconfig can pass the options which
> > start with "kernel." prefix to kernel command line, so;
> > 
> > (echo "kernel.sysctl {"; cat "/etc/sysctl.conf"; echo "}") >> sysctl.bconf
> > bootconfig -a sysctl.bconf /boot/initrd.img
> 
> Hmm I hope I figure out if the way virtme creates initrd on the fly supports
> hooking a bootconfig addition :)

Would you mean how to hook the mkinitrd to add /etc/bootconfig?

Thank you,

> 


-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH v2 0/3] support setting sysctl parameters from kernel command line

[Luis Chamberlain]

On Thu, Apr 16, 2020 at 03:02:06PM +0900, Masami Hiramatsu wrote:
> Hi Luis,
> 
> On Wed, 15 Apr 2020 06:30:41 +0000
> Luis Chamberlain <mcgrof@kernel.org> wrote:
> > Currently the maximum config size size is 32KB and the total key-words
> > (not     key-value entries) must be under 1024 nodes.  Note: this is not
> > the number of entries but nodes, an entry must consume more than 2 nodes
> > (a key-word and a value). So theoretically, it will be up to 512
> > key-value pairs. If keys contains 3 words in average, it can contain 256
> > key-value pairs. In most cases, the number of config items will be under
> > 100 entries and smaller than 8KB, so it would be enough.  If the node
> > number exceeds 1024, parser returns an error even if the file       size
> > is smaller than 32KB.  Anyway, since bootconfig command verifies it when
> > appending a boot config       to initrd image, user can notice it before
> > boot.  
> > ```
> > *recommending* bootconfig due to the limitation of cmdline seems
> > sensible, however if we advise that.. wouldn't the space for 512
> > theoretical entries full up rather fast?
> 
> Yeah, I think it is easier to hit the node number limitation rather
> than fill up the space. However, since the bootconfig supports comments,
> if user writes enough readable config file, I think it's probably the
> right balance :)
> If you think the 512 entries is too small, it is easy to expand it
> upto 32K (64K nodes). But it may consume 512KB memory only for the
> node (meta) data. Current 1024 nodes consumes 8KB (8bytes/node), so
> compared with the max data size (32KB), I think it is a better balance.

Yeah, and well at least x86 / x86_64 sets COMMAND_LINE_SIZE to 2048
right now (2 KB), that'd hit the limit of abuse of cmdline pretty fast
too. I see no way to scale this reasonably if people abuse syctls on
the command line but to use bootconfig and bite the bullet on size,
to keep sanity.

  Luis

Re: [PATCH v2 1/3] kernel/sysctl: support setting sysctl parameters from kernel command line

[Masami Hiramatsu]

Hi Luis,

On Thu, 16 Apr 2020 01:29:31 +0000
Luis Chamberlain <mcgrof@kernel.org> wrote:

> On Wed, Apr 15, 2020 at 06:03:55PM +0900, Masami Hiramatsu wrote:
> > On Tue, 14 Apr 2020 13:32:20 +0200
> > Vlastimil Babka <vbabka@suse.cz> wrote:
> > > diff --git a/init/main.c b/init/main.c
> > > index a48617f2e5e5..7b43118215d6 100644
> > > --- a/init/main.c
> > > +++ b/init/main.c
> > > @@ -1372,6 +1372,8 @@ static int __ref kernel_init(void *unused)
> > >  
> > >  	rcu_end_inkernel_boot();
> > >  
> > > +	do_sysctl_args();
> > > +
> > 
> > Ah, I see. Since the sysctl is designed to be called after all __init calls were
> > done, it shouldn't use bootconfig directly because bootconfig is full of __init
> > call.
> 
> The idea is bootconfig would be useful in the sense of a library set of
> helpers which could be modified to remove __init, and then used to
> instrument the cmdline depending on certain debugging kconfig entries.

Would you mean making bootconfig (parser and APIs) be more generic so that
other subsystem can reuse it with their data?
Or just make it available after boot? (I think this latter one will be
useful for module initialization)

> We currently have no way to purposely extend / break the cmdline for
> debugging purposes, so, bootconfig's parsers, since it already has a
> way to extend the cmdlineline, might make it much easier to do this
> later.
> 
> Without bootconfig, if we wanted to add new kconfig to, for example,
> add new funny cmdline arguments to test they worked or not, we'd have
> to devise our own set of helpers now. ie, new functionality. bootconfig
> however already has existing functionality to tweak the cmdline, and so
> some code could be leveraged there for this purpose.

Hmm, you can use the bootconfig as a "supplemental" kernel command line,
but not tweak (like modify/replace) it. Would you like to change the
kernel command line parameter on-line?

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH v2 1/3] kernel/sysctl: support setting sysctl parameters from kernel command line

[Luis Chamberlain]

On Thu, Apr 16, 2020 at 07:49:55PM +0900, Masami Hiramatsu wrote:
> Hi Luis,
> 
> On Thu, 16 Apr 2020 01:29:31 +0000
> Luis Chamberlain <mcgrof@kernel.org> wrote:
> 
> > On Wed, Apr 15, 2020 at 06:03:55PM +0900, Masami Hiramatsu wrote:
> > > On Tue, 14 Apr 2020 13:32:20 +0200
> > > Vlastimil Babka <vbabka@suse.cz> wrote:
> > > > diff --git a/init/main.c b/init/main.c
> > > > index a48617f2e5e5..7b43118215d6 100644
> > > > --- a/init/main.c
> > > > +++ b/init/main.c
> > > > @@ -1372,6 +1372,8 @@ static int __ref kernel_init(void *unused)
> > > >  
> > > >  	rcu_end_inkernel_boot();
> > > >  
> > > > +	do_sysctl_args();
> > > > +
> > > 
> > > Ah, I see. Since the sysctl is designed to be called after all __init calls were
> > > done, it shouldn't use bootconfig directly because bootconfig is full of __init
> > > call.
> > 
> > The idea is bootconfig would be useful in the sense of a library set of
> > helpers which could be modified to remove __init, and then used to
> > instrument the cmdline depending on certain debugging kconfig entries.
> 
> Would you mean making bootconfig (parser and APIs) be more generic so that
> other subsystem can reuse it with their data?
> Or just make it available after boot? (I think this latter one will be
> useful for module initialization)

The later. First use case that comes to mind is debugging cmdline, so
to see if what one adds is what ends up happening at run time after
boot.

> > We currently have no way to purposely extend / break the cmdline for
> > debugging purposes, so, bootconfig's parsers, since it already has a
> > way to extend the cmdlineline, might make it much easier to do this
> > later.
> > 
> > Without bootconfig, if we wanted to add new kconfig to, for example,
> > add new funny cmdline arguments to test they worked or not, we'd have
> > to devise our own set of helpers now. ie, new functionality. bootconfig
> > however already has existing functionality to tweak the cmdline, and so
> > some code could be leveraged there for this purpose.
> 
> Hmm, you can use the bootconfig as a "supplemental" kernel command line,
> but not tweak (like modify/replace) it. Would you like to change the
> kernel command line parameter on-line?

It would be during boot. To augment it as if the user had used certain
parameters on boot. But if only a new path is tested, and we can't
reproduce as if the user had *not* used bootconfig, this idea would
only be useful to test bootconfig parsing, nothing else. The hope was
to do both.

  Luis

Re: [PATCH v2 1/3] kernel/sysctl: support setting sysctl parameters from kernel command line

[Masami Hiramatsu]

On Thu, 16 Apr 2020 15:53:27 +0000
Luis Chamberlain <mcgrof@kernel.org> wrote:

> On Thu, Apr 16, 2020 at 07:49:55PM +0900, Masami Hiramatsu wrote:
> > Hi Luis,
> > 
> > On Thu, 16 Apr 2020 01:29:31 +0000
> > Luis Chamberlain <mcgrof@kernel.org> wrote:
> > 
> > > On Wed, Apr 15, 2020 at 06:03:55PM +0900, Masami Hiramatsu wrote:
> > > > On Tue, 14 Apr 2020 13:32:20 +0200
> > > > Vlastimil Babka <vbabka@suse.cz> wrote:
> > > > > diff --git a/init/main.c b/init/main.c
> > > > > index a48617f2e5e5..7b43118215d6 100644
> > > > > --- a/init/main.c
> > > > > +++ b/init/main.c
> > > > > @@ -1372,6 +1372,8 @@ static int __ref kernel_init(void *unused)
> > > > >  
> > > > >  	rcu_end_inkernel_boot();
> > > > >  
> > > > > +	do_sysctl_args();
> > > > > +
> > > > 
> > > > Ah, I see. Since the sysctl is designed to be called after all __init calls were
> > > > done, it shouldn't use bootconfig directly because bootconfig is full of __init
> > > > call.
> > > 
> > > The idea is bootconfig would be useful in the sense of a library set of
> > > helpers which could be modified to remove __init, and then used to
> > > instrument the cmdline depending on certain debugging kconfig entries.
> > 
> > Would you mean making bootconfig (parser and APIs) be more generic so that
> > other subsystem can reuse it with their data?
> > Or just make it available after boot? (I think this latter one will be
> > useful for module initialization)
> 
> The later. First use case that comes to mind is debugging cmdline, so
> to see if what one adds is what ends up happening at run time after
> boot.

Hmm, I think that's not so easy to debug command line after boot, because
the kernel command line is parsed (and handlers are executed) already in
boot time. We can not repeat it after boot.

> > > We currently have no way to purposely extend / break the cmdline for
> > > debugging purposes, so, bootconfig's parsers, since it already has a
> > > way to extend the cmdlineline, might make it much easier to do this
> > > later.
> > > 
> > > Without bootconfig, if we wanted to add new kconfig to, for example,
> > > add new funny cmdline arguments to test they worked or not, we'd have
> > > to devise our own set of helpers now. ie, new functionality. bootconfig
> > > however already has existing functionality to tweak the cmdline, and so
> > > some code could be leveraged there for this purpose.
> > 
> > Hmm, you can use the bootconfig as a "supplemental" kernel command line,
> > but not tweak (like modify/replace) it. Would you like to change the
> > kernel command line parameter on-line?
> 
> It would be during boot. To augment it as if the user had used certain
> parameters on boot. But if only a new path is tested, and we can't
> reproduce as if the user had *not* used bootconfig, this idea would
> only be useful to test bootconfig parsing, nothing else. The hope was
> to do both.

As you may know, the bootconfig already supports "additional" kernel
command line. All keys which starts "kernel" is copied into kernel
command line at early boot timing. So if you want to write a test
parameter in the bootconfig, you can do it.

However, it is not a good idea to execute command line handlers
twice because it can be destructive or can append all parameters
(e.g. "console=" .)

For the new feature can natively use the bootconfig, for example
boot-time tracing (kernel/trace/trace_boot.c) is something like
this sysctl on boot, and natively uses the bootconfig because
the tracing parameter is too complex for kernel command line :)

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH v2 1/3] kernel/sysctl: support setting sysctl parameters from kernel command line

[Luis Chamberlain]

On Fri, Apr 17, 2020 at 07:34:42PM +0900, Masami Hiramatsu wrote:
> On Thu, 16 Apr 2020 15:53:27 +0000
> Luis Chamberlain <mcgrof@kernel.org> wrote:
> 
> > On Thu, Apr 16, 2020 at 07:49:55PM +0900, Masami Hiramatsu wrote:
> > > Hi Luis,
> > > 
> > > On Thu, 16 Apr 2020 01:29:31 +0000
> > > Luis Chamberlain <mcgrof@kernel.org> wrote:
> > > 
> > > > On Wed, Apr 15, 2020 at 06:03:55PM +0900, Masami Hiramatsu wrote:
> > > > > On Tue, 14 Apr 2020 13:32:20 +0200
> > > > > Vlastimil Babka <vbabka@suse.cz> wrote:
> > > > > > diff --git a/init/main.c b/init/main.c
> > > > > > index a48617f2e5e5..7b43118215d6 100644
> > > > > > --- a/init/main.c
> > > > > > +++ b/init/main.c
> > > > > > @@ -1372,6 +1372,8 @@ static int __ref kernel_init(void *unused)
> > > > > >  
> > > > > >  	rcu_end_inkernel_boot();
> > > > > >  
> > > > > > +	do_sysctl_args();
> > > > > > +
> > > > > 
> > > > > Ah, I see. Since the sysctl is designed to be called after all __init calls were
> > > > > done, it shouldn't use bootconfig directly because bootconfig is full of __init
> > > > > call.
> > > > 
> > > > The idea is bootconfig would be useful in the sense of a library set of
> > > > helpers which could be modified to remove __init, and then used to
> > > > instrument the cmdline depending on certain debugging kconfig entries.
> > > 
> > > Would you mean making bootconfig (parser and APIs) be more generic so that
> > > other subsystem can reuse it with their data?
> > > Or just make it available after boot? (I think this latter one will be
> > > useful for module initialization)
> > 
> > The later. First use case that comes to mind is debugging cmdline, so
> > to see if what one adds is what ends up happening at run time after
> > boot.
> 
> Hmm, I think that's not so easy to debug command line after boot, because
> the kernel command line is parsed (and handlers are executed) already in
> boot time. We can not repeat it after boot.

Unless you put into the command line everything you need to test on one
boot.

> > > > We currently have no way to purposely extend / break the cmdline for
> > > > debugging purposes, so, bootconfig's parsers, since it already has a
> > > > way to extend the cmdlineline, might make it much easier to do this
> > > > later.
> > > > 
> > > > Without bootconfig, if we wanted to add new kconfig to, for example,
> > > > add new funny cmdline arguments to test they worked or not, we'd have
> > > > to devise our own set of helpers now. ie, new functionality. bootconfig
> > > > however already has existing functionality to tweak the cmdline, and so
> > > > some code could be leveraged there for this purpose.
> > > 
> > > Hmm, you can use the bootconfig as a "supplemental" kernel command line,
> > > but not tweak (like modify/replace) it. Would you like to change the
> > > kernel command line parameter on-line?
> > 
> > It would be during boot. To augment it as if the user had used certain
> > parameters on boot. But if only a new path is tested, and we can't
> > reproduce as if the user had *not* used bootconfig, this idea would
> > only be useful to test bootconfig parsing, nothing else. The hope was
> > to do both.
> 
> As you may know, the bootconfig already supports "additional" kernel
> command line. All keys which starts "kernel" is copied into kernel
> command line at early boot timing. So if you want to write a test
> parameter in the bootconfig, you can do it.

There are two bootparams paths now, the old way, and the new bootconfig
path. Extending test coverage to test bootconfig seems rather easier to
consider. However the hope was that there may be some existing code
within bootconfig which would also allow one to test the old cmdline
path, as if the cmdline had certain params present. It doesn't seem
to be the case.

> However, it is not a good idea to execute command line handlers
> twice because it can be destructive or can append all parameters
> (e.g. "console=" .)

I see so bootconfig is mutually exclusive with the old cmdline?

> For the new feature can natively use the bootconfig, for example
> boot-time tracing (kernel/trace/trace_boot.c) is something like
> this sysctl on boot, and natively uses the bootconfig because
> the tracing parameter is too complex for kernel command line :)

Neat.

  Luis

Re: [PATCH v2 1/3] kernel/sysctl: support setting sysctl parameters from kernel command line

[Masami Hiramatsu]

On Fri, 17 Apr 2020 16:59:39 +0000
Luis Chamberlain <mcgrof@kernel.org> wrote:

> > > > > > Ah, I see. Since the sysctl is designed to be called after all __init calls were
> > > > > > done, it shouldn't use bootconfig directly because bootconfig is full of __init
> > > > > > call.
> > > > > 
> > > > > The idea is bootconfig would be useful in the sense of a library set of
> > > > > helpers which could be modified to remove __init, and then used to
> > > > > instrument the cmdline depending on certain debugging kconfig entries.
> > > > 
> > > > Would you mean making bootconfig (parser and APIs) be more generic so that
> > > > other subsystem can reuse it with their data?
> > > > Or just make it available after boot? (I think this latter one will be
> > > > useful for module initialization)
> > > 
> > > The later. First use case that comes to mind is debugging cmdline, so
> > > to see if what one adds is what ends up happening at run time after
> > > boot.
> > 
> > Hmm, I think that's not so easy to debug command line after boot, because
> > the kernel command line is parsed (and handlers are executed) already in
> > boot time. We can not repeat it after boot.
> 
> Unless you put into the command line everything you need to test on one
> boot.

I got it. But it requires completely another thing, because the command line
handlers are __init function, which is also released after boot, and bootconfig
is not designed for update (read only) so that we can remove locks.

> 
> > > > > We currently have no way to purposely extend / break the cmdline for
> > > > > debugging purposes, so, bootconfig's parsers, since it already has a
> > > > > way to extend the cmdlineline, might make it much easier to do this
> > > > > later.
> > > > > 
> > > > > Without bootconfig, if we wanted to add new kconfig to, for example,
> > > > > add new funny cmdline arguments to test they worked or not, we'd have
> > > > > to devise our own set of helpers now. ie, new functionality. bootconfig
> > > > > however already has existing functionality to tweak the cmdline, and so
> > > > > some code could be leveraged there for this purpose.
> > > > 
> > > > Hmm, you can use the bootconfig as a "supplemental" kernel command line,
> > > > but not tweak (like modify/replace) it. Would you like to change the
> > > > kernel command line parameter on-line?
> > > 
> > > It would be during boot. To augment it as if the user had used certain
> > > parameters on boot. But if only a new path is tested, and we can't
> > > reproduce as if the user had *not* used bootconfig, this idea would
> > > only be useful to test bootconfig parsing, nothing else. The hope was
> > > to do both.
> > 
> > As you may know, the bootconfig already supports "additional" kernel
> > command line. All keys which starts "kernel" is copied into kernel
> > command line at early boot timing. So if you want to write a test
> > parameter in the bootconfig, you can do it.
> 
> There are two bootparams paths now, the old way, and the new bootconfig
> path. Extending test coverage to test bootconfig seems rather easier to
> consider. However the hope was that there may be some existing code
> within bootconfig which would also allow one to test the old cmdline
> path, as if the cmdline had certain params present. It doesn't seem
> to be the case.

Hmm, maybe you misunderstand how the bootconfig passes the options
to command line. At the very early timing, it copies the kernel
boot options into the existing legacy kernel command line. See
setup_command_line()@init/main.c. The extra_command_line is what the
bootconfig generated.

This extra_command_line is mixed with the old cmdline parameters
and it is passed to the handlers via parse_args() on each init-level.
(some handlers just set the option to its own variables and
 use those variables in their __init functions)

On the other hand, new code which uses the bootconfig, will use the
bootconfig APIs (xbc_*) to find their related options in its __init
functions.

> > However, it is not a good idea to execute command line handlers
> > twice because it can be destructive or can append all parameters
> > (e.g. "console=" .)
> 
> I see so bootconfig is mutually exclusive with the old cmdline?

If you put options under "kernel" or "init", those are inclusive to the
old cmdline, but other keys are not visible from the old cmdline.

Thank you,

> 
> > For the new feature can natively use the bootconfig, for example
> > boot-time tracing (kernel/trace/trace_boot.c) is something like
> > this sysctl on boot, and natively uses the bootconfig because
> > the tracing parameter is too complex for kernel command line :)
> 
> Neat.
> 
>   Luis


-- 
Masami Hiramatsu <mhiramat@kernel.org>