From: Rusty Russell <rusty@rustcorp.com.au>
To: Andy Lutomirski <luto@amacapital.net>
Cc: linux-kernel@vger.kernel.org,
Ben Hutchings <bhutchings@solarflare.com>,
linux-kbuild@vger.kernel.org
Subject: Re: [RFC PATCH] Allow optional module parameters
Date: Mon, 18 Mar 2013 12:54:14 +1030 [thread overview]
Message-ID: <87sj3tsawh.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CALCETrU+rehQzy4vVg589CGi561X_s73Xgsfp43pYZOoKvNDXQ@mail.gmail.com>
Andy Lutomirski <luto@amacapital.net> writes:
> On Thu, Mar 14, 2013 at 10:03 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> Andy Lutomirski <luto@amacapital.net> writes:
>>> Current parameter behavior is odd. Boot parameters that have values
>>> and don't match anything become environment variables, with no
>>> warning. Boot parameters without values that don't match anything
>>> go into argv_init. Everything goes into /proc/cmdline.
>>>
>>> The init_module and finit_module syscalls, however, are strict:
>>> parameters that don't match result in -ENOENT.
>>>
>>> kmod (and hence modprobe), when loading a module called foo, look in
>>> /proc/cmdline for foo.x or foo.x=y, strip off the foo., and pass the
>>> rest to init_module.
>>>
>>> The upshot is that booting with module.nonexistent_parameter=1 is
>>> okay if module is built in or missing entirely but prevents module
>>> from loading if it's an actual module. Similarly, option module
>>> nonexistent_parameter=1 in /etc/modprobe.d prevents the module from
>>> loading the parameter goes away. This means that removing module
>>> parameters unnecessarily breaks things.
>>
>> Err, yes. Don't remove module parameters, they're part of the API. Do
>> you have a particular example?
>
> So things like i915.i915_enable_ppgtt, which is there to enable
> something experimental, needs to stay forever once the relevant
> feature becomes non-experimental and non-optional? This seems silly.
Well, it's either experimental, in which case you're happy to break
users who use it, or it's not, in which case, don't.
> Having the module parameter go away while still allowing the module to
> load seems like a good solution (possibly with a warning in the logs
> so the user can eventually delete the parameter).
Why not do that for *every* missing parameter then? Why have this weird
notation where the user must know that the parameter might one day go
away?
> In any case, I find it odd that the only parameters you can set that
> cause errors when the parameter is deleted are parameters for modules
> that are built as modules.
We could definitely expand the check: we should check for unknown
parameters to builtin modules.
This refers back to my question on lkml 'Re: No sysfs directory for
openvswitch module when built-in' as the kernel doesn't currently know
what modules are builtin. We intuit it from parameter names, which is
sloppy.
Here's a rough patch. Maybe someone on linux-kbuild can tell me why it
fails?
DOESNT_WORK: kernel: generate list of builtin modnames.
For some reason, the only contents of modules.builtin when this runs is
one line "kernel/kernel/configs.ko"?
This lets us emit an error when invalid boot parameters are used, since
we know what names can never be external modules.
diff --git a/include/linux/module.h b/include/linux/module.h
index 46f1ea0..3433f6b 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -186,6 +186,9 @@ struct notifier_block;
#ifdef CONFIG_MODULES
+/* In generated file kernel/modnamelist.c */
+extern const char *builtin_modnames[];
+
extern int modules_disabled; /* for sysctl */
/* Get/put a kernel symbol (calls must be symmetric) */
void *__symbol_get(const char *symbol);
diff --git a/init/main.c b/init/main.c
index 63534a1..e4dec79 100644
--- a/init/main.c
+++ b/init/main.c
@@ -245,12 +245,25 @@ static int __init repair_env_string(char *param, char *val, const char *unused)
return 0;
}
+static bool builtin_modname(const char *name, size_t len)
+{
+ const char **n;
+
+ for (n = builtin_modnames; *n; n++) {
+ if (strncmp(name, *n, len) == 0 && !(*n)[len])
+ return true;
+ }
+ return false;
+}
+
/*
* Unknown boot options get handed to init, unless they look like
* unused parameters (modprobe will find them in /proc/cmdline).
*/
static int __init unknown_bootoption(char *param, char *val, const char *unused)
{
+ size_t modname_len = strcspn(param, ".");
+
repair_env_string(param, val, unused);
/* Handle obsolete-style parameters */
@@ -258,8 +271,13 @@ static int __init unknown_bootoption(char *param, char *val, const char *unused)
return 0;
/* Unused module parameter. */
- if (strchr(param, '.') && (!val || strchr(param, '.') < val))
+ if (param[modname_len] == '.') {
+ if (builtin_modname(param, modname_len)) {
+ printk(KERN_ERR "Unknown kernel parameter %s\n", param);
+ return -EINVAL;
+ }
return 0;
+ }
if (panic_later)
return 0;
diff --git a/kernel/.gitignore b/kernel/.gitignore
index ab4f109..df5b7c7 100644
--- a/kernel/.gitignore
+++ b/kernel/.gitignore
@@ -4,3 +4,4 @@
config_data.h
config_data.gz
timeconst.h
+modnamelist.c
diff --git a/kernel/Makefile b/kernel/Makefile
index bbde5f1..3f3dad7 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -10,7 +10,7 @@ obj-y = fork.o exec_domain.o panic.o printk.o \
kthread.o wait.o sys_ni.o posix-cpu-timers.o mutex.o \
hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o \
notifier.o ksysfs.o cred.o \
- async.o range.o groups.o lglock.o smpboot.o
+ async.o range.o groups.o lglock.o smpboot.o modnamelist.o
ifdef CONFIG_FUNCTION_TRACER
# Do not trace debug files and internal ftrace files
@@ -139,6 +139,13 @@ targets += timeconst.h
$(obj)/timeconst.h: $(obj)/hz.bc $(src)/timeconst.bc FORCE
$(call if_changed,bc)
+quiet_cmd_modnamelist = MODNAMELIST $@
+ cmd_modnamelist = sh scripts/modnamelist.sh $@ $(src)/modules.builtin
+
+# Must match name-fix in scripts/Makefile.lib!
+kernel/modnamelist.c: modules.builtin FORCE
+ $(call if_changed,modnamelist)
+
ifeq ($(CONFIG_MODULE_SIG),y)
#
# Pull the signing certificate and any extra certificates into the kernel
diff --git a/scripts/modnamelist.sh b/scripts/modnamelist.sh
new file mode 100755
index 0000000..5d06820
--- /dev/null
+++ b/scripts/modnamelist.sh
@@ -0,0 +1,22 @@
+#! /bin/sh
+set -e
+
+OUT="$1"
+LIST="$2"
+
+trap "rm -f $OUT.tmp" 0
+
+cat > $OUT.tmp <<EOF
+/* Autogenerated list of builtin modules. */
+#include <linux/module.h>
+
+const char *builtin_modnames[] = {
+EOF
+
+sed -e 's@.*/\(.*\)\.ko@\t"\1"@' -e 's@[,-]@_@g' -e 's@$@,@' < $LIST >> $OUT.tmp
+cat >> $OUT.tmp <<EOF
+ NULL
+};
+EOF
+
+mv $OUT.tmp $OUT
next parent reply other threads:[~2013-03-18 2:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <b6b1676fd5bcd6b0ef47b0e0a1c26b1c05684135.1363291511.git.luto@amacapital.net>
[not found] ` <87ehfhtftn.fsf@rustcorp.com.au>
[not found] ` <CALCETrU+rehQzy4vVg589CGi561X_s73Xgsfp43pYZOoKvNDXQ@mail.gmail.com>
2013-03-18 2:24 ` Rusty Russell [this message]
2013-03-18 17:42 ` [RFC PATCH] Allow optional module parameters Andy Lutomirski
2013-03-19 2:32 ` Rusty Russell
2013-03-19 19:40 ` Ben Hutchings
2013-03-20 2:31 ` Rusty Russell
2013-03-20 0:26 ` Lucas De Marchi
2013-03-20 0:32 ` Andy Lutomirski
2013-03-20 0:36 ` Andy Lutomirski
2013-03-20 3:45 ` Rusty Russell
2013-07-01 6:50 ` Rusty Russell
2013-07-01 16:33 ` Jonathan Masters
2013-07-03 0:28 ` Rusty Russell
2013-07-03 21:03 ` Michal Marek
2013-07-03 21:17 ` Andy Lutomirski
2013-07-03 21:23 ` Michal Marek
2013-07-03 21:30 ` Yann E. MORIN
2013-07-03 21:31 ` Lucas De Marchi
2013-07-03 21:36 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sj3tsawh.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=bhutchings@solarflare.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox