Bug#820010: [PATCH v2] libkmod: Add support for detached module signatures
On Wed, Apr 13, 2016 at 7:00 AM, Ben Hutchings <b...@decadent.org.uk> wrote: > On Wed, 2016-04-13 at 01:05 -0300, Lucas De Marchi wrote: >> Hi, >> >> CC'ing Rusty >> >> On Mon, Apr 4, 2016 at 9:32 PM, Ben Hutchings <b...@decadent.org.uk> wrote: >> > >> > Debian will not sign modules during the kernel package build, as this >> > conflicts with the goal of reproducible builds. Instead, we will >> > generate detached signatures offline and include them in a second >> > package. >> Is this a decision already? It doesn't look as a good reason - you >> would already need to provide a signing key (CONFIG_MODULE_SIG_KEY) >> anyway for this to work. How is leaving the module signature in >> another package be any better than just signing the module? If you >> have the signature, the build is just as reproducible as before. > > I think we may have different ideas about what reproducibility means. > When I say reproducible I mean *anyone* with the right tools installed > can reproduce the binary packages (.deb) from the source package (.dsc > and tarballs). > > The signing key obviously isn't available to everyone, so the source > package has to include detached signatures prepared outside of the And how is this signature prepared? Since it needs the compiled module it would be a matter of changing the compiler, even minor version, to invalidate the argument of reproducible build. It seems very fragile to me. > package build process. But we can't put them in the linux source > package, because that results in a dependency loop. > >> > >> > We could attach the signatures when building this second package or at >> > installation time, but that leads to duplication of all modules, >> > either in the archive or on users' systems. >> > >> > To avoid this, add support to libkmod for concatenating modules with >> > detached signatures (files with the '.sig' extension) at load time. >> this has the drawback that finit_module() can't be used. > > So does module compression, but it's still a supported option. This is easily fixed by teaching the kernel to handle the fd as a compressed file. The kernel already has the routines to uncompress them anyway. Supporting detached signatures means it can't be fixed anymore since we will have to use init_module() rather than finit_module(). Lucas De Marchi
Bug#820010: [PATCH v2] libkmod: Add support for detached module signatures
Hi,
CC'ing Rusty
On Mon, Apr 4, 2016 at 9:32 PM, Ben Hutchings <b...@decadent.org.uk> wrote:
> Debian will not sign modules during the kernel package build, as this
> conflicts with the goal of reproducible builds. Instead, we will
> generate detached signatures offline and include them in a second
> package.
Is this a decision already? It doesn't look as a good reason - you
would already need to provide a signing key (CONFIG_MODULE_SIG_KEY)
anyway for this to work. How is leaving the module signature in
another package be any better than just signing the module? If you
have the signature, the build is just as reproducible as before.
> We could attach the signatures when building this second package or at
> installation time, but that leads to duplication of all modules,
> either in the archive or on users' systems.
>
> To avoid this, add support to libkmod for concatenating modules with
> detached signatures (files with the '.sig' extension) at load time.
this has the drawback that finit_module() can't be used.
> Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
> ---
> v2: Fix syntax error in the xz case
>
> Missed this because I didn't realise the Debian package disables gzip
> and xz support.
>
> Ben.
>
> libkmod/libkmod-file.c | 110
> +
> 1 file changed, 103 insertions(+), 7 deletions(-)
>
> diff --git a/libkmod/libkmod-file.c b/libkmod/libkmod-file.c
> index 5eeba6a912a2..cb1da3c9e2ae 100644
> --- a/libkmod/libkmod-file.c
> +++ b/libkmod/libkmod-file.c
...
> @@ -292,12 +370,25 @@ struct kmod_file *kmod_file_open(const struct kmod_ctx
> *ctx,
> if (file == NULL)
> return NULL;
>
> + file->sig_fd = -1;
> +
> file->fd = open(filename, O_RDONLY|O_CLOEXEC);
> if (file->fd < 0) {
> err = -errno;
> goto error;
> }
>
> + /* Try to open a detached signature. If it's missing, that's OK. */
> + if (asprintf(_filename, "%s.sig", filename) < 0) {
> + err = -errno;
> + goto error;
> + }
> + file->sig_fd = open(sig_filename, O_RDONLY|O_CLOEXEC);
> + if (file->sig_fd < 0 && errno != ENOENT) {
> + err = -errno;
> + goto error;
> + }
This can't really work if the module is being loaded uncompressed (I
think nowadays we can even add support for compressed modules...
Rusty, any input here?).
When the module is being directly loaded, the direct flag gets set so
kmod_module_insert_module() knows it can try to use finit_module().
Since you have an external signature what would happen is that we
would load the signature, but try to load the module in the kernel
without it.
I'm still not convinced the split module + signature is actually a good thing.
Lucas De Marchi
Bug#810367: [PATCH] depmod: Don't insert comment in modules.devname if otherwise empty
On Sun, Jan 10, 2016 at 1:10 PM, Josh Triplett <j...@joshtriplett.org> wrote:
> This allows tools to detect the file as empty, such as via systemd's
> ConditionFileNotEmpty.
> ---
>
> The string constant extends past 80 columns, per CODING-STYLE.
>
> The motivation for this patch came from Debian bug 810367. This change
> would allow kmod-static-nodes.service to use ConditionFileNotEmpty
> instead of ConditionPathExists.
>
> tools/depmod.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/tools/depmod.c b/tools/depmod.c
> index a585d47..6e9bb4d 100644
> --- a/tools/depmod.c
> +++ b/tools/depmod.c
> @@ -1999,8 +1999,7 @@ static int output_builtin_bin(struct depmod *depmod,
> FILE *out)
> static int output_devname(struct depmod *depmod, FILE *out)
> {
> size_t i;
> -
> - fputs("# Device nodes to trigger on-demand module loading.\n", out);
> + bool empty = true;
>
> for (i = 0; i < depmod->modules.count; i++) {
> const struct mod *mod = depmod->modules.array[i];
> @@ -2036,10 +2035,15 @@ static int output_devname(struct depmod *depmod, FILE
> *out)
> }
>
> if (devname != NULL) {
> - if (type != '\0')
> + if (type != '\0') {
> + if (empty) {
> + fputs("# Device nodes to trigger
> on-demand module loading.\n",
> + out);
> + empty = false;
> + }
> fprintf(out, "%s %s %c%u:%u\n", mod->modname,
> devname, type, major, minor);
> - else
> +} else
> ERR("Module '%s' has devname (%s) but "
> "lacks major and minor information. "
> "Ignoring.\n", mod->modname, devname);
> --
Applied, thanks.
Lucas De Marchi
Bug#810367: [PATCH] depmod: Don't insert comment in modules.devname if otherwise empty
Hi Martin On Mon, Jan 11, 2016 at 1:55 PM, Martin Pitt <mp...@debian.org> wrote: > Hey Josh, Lucas, > > Lucas De Marchi [2016-01-11 10:43 -0200]: >> On Sun, Jan 10, 2016 at 1:10 PM, Josh Triplett <j...@joshtriplett.org> wrote: >> > This allows tools to detect the file as empty, such as via systemd's >> > ConditionFileNotEmpty. > > As pointed out on https://github.com/systemd/systemd/pull/2301: Why > does this file get created at all if it's going to be empty? The only reason I can think of is to avoid breaking current programs that depend on its existence since it is created since forever. Lucas De Marchi
Bug#763266: codespell: Trying next encoding: utf-8
On Sun, Sep 28, 2014 at 9:18 PM, Paul Wise p...@debian.org wrote: Control: tags -1 + patch upstream Control: forwarded -1 codesp...@googlegroups.com On Sun, 2014-09-28 at 19:56 +0200, Jakub Wilk wrote: Package: codespell Severity: minor $ printf '\xff' test $ codespell test WARNING: Decoding file test WARNING: using encoding=utf-8 failed. WARNING: Trying next encoding: utf-8 Of course if encoding=utf-8 failed, there is no point trying utf-8 again. The last line should instead read: WARNING: Trying next encoding: iso-8859-1 The attached patch fixes this issue. Applied. Thanks. -- Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742207: [PATCH] Update the handling of colour output for more use-cases.
On Sat, Mar 22, 2014 at 3:05 AM, Paul Wise pa...@bonedaddy.net wrote: Disable colours when stdout is not a terminal by default. Add an option to enable colours when stdout is not a terminal. Fixes: https://bugs.debian.org/742207 --- Applied. Thanks. Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742207: [PATCH] Disable colours when stdout is not a terminal
On Thu, Mar 20, 2014 at 11:37 PM, Paul Wise pa...@bonedaddy.net wrote: --- codespell.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/codespell.py b/codespell.py index fdbd5cb..816593c 100755 --- a/codespell.py +++ b/codespell.py @@ -478,7 +478,7 @@ def main(*args): build_dict(options.dictionary) colors = TermColors(); -if options.disable_colors: +if options.disable_colors or not sys.stdout.isatty(): I think we need a way to disable it by default if it's not a tty, but not impose it. IMO it's a pain to review big projects without color, so in general I save to a file and review with less, that is capable of displaying the colors. Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674110: modprobe: ../tools/kmod-modprobe.c:550
On Fri, Mar 15, 2013 at 12:34 AM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: On Mar 14, 2013 4:25 PM, Alberto Milone alberto.mil...@canonical.com wrote: On 14/03/13 23:34, Lucas De Marchi wrote: Do you realize you are quoting the man page of modutils? It's not kmod or module-init-tools, which kmod replaced. It's the old modutils used with Linux 2.4. kmod is a drop-in replacement to m-i-t, but we are not putting back the things from modutils if we don't have a reason to. It wasn't documented in m-i-t but it was supported. See line 167 of the following file: https://github.com/vadmium/module-init-tools/blob/master/generate-modprobe.conf This script shows exactly the opposite... it was not supported in m-i-t and thus they were converted to install commands using /bin/true Why do you want to get the initstate of an inexistent module? Why do you think null and off should be special? And more important, you still didn't answer why the available options are not working for you - you said you cannot get the initstate - but that is a non-issue since libkmod shouldn't even try to get the initstate. Please give some real example of what you are trying to do so we can figure out a solution. All I'm saying is that modprobe raises an error if it finds strings such as the following in configuration files in /etc/modprobe.d/ : alias nouveau off And it's right to complain, it's not something valid in the configuration It never was, even in m-i-t. As in comment 15, this is particularly annoying when it causes update-initramfs to fail: update-initramfs: Generating /boot/initrd.img-3.8.0-3-generic modprobe: ../tools/modprobe.c:550: print_action: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed. Aborted (core dumped) It seems that update-initramfs calls modprobe in the following way: modprobe --set-version=3.8.0-3-generic --ignore-install --quiet --show-depends nouveau Ok... I pushed an alternative fix to have the same behavior as for modprobe (except the exit code). As I said off and null are note special, and they weren't in module-init-tools neither. The thing we were doing wrong is that in presence of an alias to anything that doesn't exist we should exit silently instead of exploding. I fixed and added a test case to the testsuite with this in the config file: alias psmouse deaddood. It's working now, at least for me. Let me know if you still have issues. Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674110: modprobe: ../tools/kmod-modprobe.c:550
On Thu, Mar 14, 2013 at 7:54 AM, Alberto Milone alberto.mil...@canonical.com wrote: On 14/03/13 03:39, Lucas De Marchi wrote: Hi Alberto First of all, please inline your patch next time, so we can comment on it. Sorry about that. On Wed, Mar 13, 2013 at 1:15 PM, Alberto Milone alberto.mil...@canonical.com wrote: Hi all, I think the problem is that modprobe looks for the module (which in this case is aliased as off) in /sys and raises an error if it doesn't find it (there's no such thing as an off module in /sys). In the attached patch I check that the module name is not off or null before doing assert(kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN). Why is off and null special? Let me quote this page: http://ccrma.stanford.edu/planetccrma/man/man5/modules.conf.5.html Note that the line: alias some_module off will make modprobe ignore requests to load that module. Another special alias is: alias some_module null which will make requests for some_module always succeed, but no module will actually be installed. This can be used as a base for stacks created via the above and below directives. Do you realize you are quoting the man page of modutils? It's not kmod or module-init-tools, which kmod replaced. It's the old modutils used with Linux 2.4. kmod is a drop-in replacement to m-i-t, but we are not putting back the things from modutils if we don't have a reason to. This solves the problem on my systems. What are you solving that is not solved by putting /bin/true or blacklisting the module? As you can see, blacklist is different from off. Furthermore udev ignores blacklist but honours off. udev uses kmod_module_probe_insert_module(mod, KMOD_PROBE_APPLY_BLACKLIST, ...) - which is the same of calling modprobe with -b option. So, it does hounours the blacklist. And, as I said, the problem is that we cannot get the initstate ( /sys/module/$module_name/initstate ) of off or null because they are Why do you want to get the initstate of an inexistent module? Why do you think null and off should be special? And more important, you still didn't answer why the available options are not working for you - you said you cannot get the initstate - but that is a non-issue since libkmod shouldn't even try to get the initstate. not real modules and using /bin/true as the installation command (if this is what you're suggesting) won't solve the problem. Please give some real example of what you are trying to do so we can figure out a solution. Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674110: modprobe: ../tools/kmod-modprobe.c:550
Hi Alberto First of all, please inline your patch next time, so we can comment on it. On Wed, Mar 13, 2013 at 1:15 PM, Alberto Milone alberto.mil...@canonical.com wrote: Hi all, I think the problem is that modprobe looks for the module (which in this case is aliased as off) in /sys and raises an error if it doesn't find it (there's no such thing as an off module in /sys). In the attached patch I check that the module name is not off or null before doing assert(kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN). Why is off and null special? This solves the problem on my systems. What are you solving that is not solved by putting /bin/true or blacklisting the module? Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689872: libkmod2: module parameters on kernel command line parsed wrong
On Mon, Oct 8, 2012 at 6:52 PM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
On Sun, Oct 7, 2012 at 2:35 PM, Marco d'Itri m...@linux.it wrote:
Any objections?
- Forwarded message from Selim T. Erdogan se...@alumni.cs.utexas.edu
-
From: Selim T. Erdogan se...@alumni.cs.utexas.edu
To: Debian Bug Tracking System sub...@bugs.debian.org
Subject: Bug#689872: libkmod2: module parameters on kernel command line
parsed
wrong
Package: libkmod2
Version: 9-2
Severity: important
Tags: d-i patch
This problem only affects module parameters given on the kernel command
line at boot time which include a '.' as part of their value. For
example libata.force=1.5Gbps. The bug causes such values to
overwrite the parameter, so this would get interpreted as parameter
5Gbps with no value. (force gets lost.)
To reproduce this safely, add testmodule.testparam=1.5G to the end of
the kernel command line at boot time. Then:
$ /sbin/modprobe -c |grep 5G
options testmodule 5G
This problem prevented me from using the wheezy beta 2 debian-installer
on a machine that needed libata.force=1.5Gbps to work properly with my
new SSD. See https://lists.debian.org/debian-boot/2012/10/msg00049.html
I'm including a very simple at the end of the report that fixes the
problem. Feel free to modify/edit as necessary. With this patch:
$ /sbin/modprobe -c |grep 5G
options testmodule testparam=1.5G
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-3-686-pae (SMP w/1 CPU core)
Locale: LANG=tr_TR.UTF-8, LC_CTYPE=tr_TR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libkmod2 depends on:
ii libc6 2.13-35
ii multiarch-support 2.13-35
libkmod2 recommends no packages.
libkmod2 suggests no packages.
-- no debconf information
*** kcmdline-option-parsing
Description: Fixes parsing of module parameters on the kernel command
line. Before this patch, if the parameter value had a '.' in it, that
would break things.
Author: Selim T. Erdoğan se...@alumni.cs.utexas.edu
--- kmod-9.orig/libkmod/libkmod-config.c
+++ kmod-9/libkmod/libkmod-config.c
@@ -542,6 +542,7 @@ static int kmod_config_parse_kcmdline(st
char buf[KCMD_LINE_SIZE];
int fd, err;
char *p, *modname, *param = NULL, *value = NULL;
+ int in_value_text = 0;
fd = open(/proc/cmdline, O_RDONLY|O_CLOEXEC);
if (fd 0) {
@@ -564,15 +565,20 @@ static int kmod_config_parse_kcmdline(st
*p = '\0';
kcmdline_parse_result(config, modname, param, value);
param = value = NULL;
+ in_value_text = 0;
modname = p + 1;
break;
case '.':
- *p = '\0';
- param = p + 1;
- break;
+ if (in_value_text == 0) {
+ *p = '\0';
+ param = p + 1;
+ break;
+ }
this fall-through here doesn't seem intentional
case '=':
- if (param != NULL)
+ if (param != NULL) {
value = p + 1;
+ in_value_text=1;
+ }
break;
}
}
Why adding another var? Isn't something like below (whitespace
damaged) sufficient?
Lucas De Marchi
diff --git a/libkmod/libkmod-config.c b/libkmod/libkmod-config.c
index 70044f0..398468e 100644
--- a/libkmod/libkmod-config.c
+++ b/libkmod/libkmod-config.c
@@ -567,8 +567,10 @@ static int kmod_config_parse_kcmdline(struct
kmod_config *config)
modname = p + 1;
break;
case '.':
- *p = '\0';
- param = p + 1;
+ if (param == NULL) {
+ *p = '\0';
+ param = p + 1;
+ }
break;
case '=':
if (param != NULL)
Just made a quick test here and it works:
└ kmod ➤ ./tools/modprobe -c | grep testmodule
options testmodule testparam=1.5G
Lucas De Marchi
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689872: libkmod2: module parameters on kernel command line parsed wrong
On Sun, Oct 7, 2012 at 2:35 PM, Marco d'Itri m...@linux.it wrote:
Any objections?
- Forwarded message from Selim T. Erdogan se...@alumni.cs.utexas.edu
-
From: Selim T. Erdogan se...@alumni.cs.utexas.edu
To: Debian Bug Tracking System sub...@bugs.debian.org
Subject: Bug#689872: libkmod2: module parameters on kernel command line parsed
wrong
Package: libkmod2
Version: 9-2
Severity: important
Tags: d-i patch
This problem only affects module parameters given on the kernel command
line at boot time which include a '.' as part of their value. For
example libata.force=1.5Gbps. The bug causes such values to
overwrite the parameter, so this would get interpreted as parameter
5Gbps with no value. (force gets lost.)
To reproduce this safely, add testmodule.testparam=1.5G to the end of
the kernel command line at boot time. Then:
$ /sbin/modprobe -c |grep 5G
options testmodule 5G
This problem prevented me from using the wheezy beta 2 debian-installer
on a machine that needed libata.force=1.5Gbps to work properly with my
new SSD. See https://lists.debian.org/debian-boot/2012/10/msg00049.html
I'm including a very simple at the end of the report that fixes the
problem. Feel free to modify/edit as necessary. With this patch:
$ /sbin/modprobe -c |grep 5G
options testmodule testparam=1.5G
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-3-686-pae (SMP w/1 CPU core)
Locale: LANG=tr_TR.UTF-8, LC_CTYPE=tr_TR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libkmod2 depends on:
ii libc6 2.13-35
ii multiarch-support 2.13-35
libkmod2 recommends no packages.
libkmod2 suggests no packages.
-- no debconf information
*** kcmdline-option-parsing
Description: Fixes parsing of module parameters on the kernel command
line. Before this patch, if the parameter value had a '.' in it, that
would break things.
Author: Selim T. Erdoğan se...@alumni.cs.utexas.edu
--- kmod-9.orig/libkmod/libkmod-config.c
+++ kmod-9/libkmod/libkmod-config.c
@@ -542,6 +542,7 @@ static int kmod_config_parse_kcmdline(st
char buf[KCMD_LINE_SIZE];
int fd, err;
char *p, *modname, *param = NULL, *value = NULL;
+ int in_value_text = 0;
fd = open(/proc/cmdline, O_RDONLY|O_CLOEXEC);
if (fd 0) {
@@ -564,15 +565,20 @@ static int kmod_config_parse_kcmdline(st
*p = '\0';
kcmdline_parse_result(config, modname, param, value);
param = value = NULL;
+ in_value_text = 0;
modname = p + 1;
break;
case '.':
- *p = '\0';
- param = p + 1;
- break;
+ if (in_value_text == 0) {
+ *p = '\0';
+ param = p + 1;
+ break;
+ }
this fall-through here doesn't seem intentional
case '=':
- if (param != NULL)
+ if (param != NULL) {
value = p + 1;
+ in_value_text=1;
+ }
break;
}
}
Why adding another var? Isn't something like below (whitespace
damaged) sufficient?
Lucas De Marchi
diff --git a/libkmod/libkmod-config.c b/libkmod/libkmod-config.c
index 70044f0..398468e 100644
--- a/libkmod/libkmod-config.c
+++ b/libkmod/libkmod-config.c
@@ -567,8 +567,10 @@ static int kmod_config_parse_kcmdline(struct
kmod_config *config)
modname = p + 1;
break;
case '.':
- *p = '\0';
- param = p + 1;
+ if (param == NULL) {
+ *p = '\0';
+ param = p + 1;
+ }
break;
case '=':
if (param != NULL)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689872: libkmod2: module parameters on kernel command line parsed wrong
On Mon, Oct 8, 2012 at 7:39 PM, Selim T. Erdogan
se...@alumni.cs.utexas.edu wrote:
On Mon, Oct 08, 2012 at 06:56:05PM -0300, Lucas De Marchi wrote:
On Mon, Oct 8, 2012 at 6:52 PM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
On Sun, Oct 7, 2012 at 2:35 PM, Marco d'Itri m...@linux.it wrote:
Any objections?
- Forwarded message from Selim T. Erdogan
se...@alumni.cs.utexas.edu -
From: Selim T. Erdogan se...@alumni.cs.utexas.edu
To: Debian Bug Tracking System sub...@bugs.debian.org
Subject: Bug#689872: libkmod2: module parameters on kernel command line
parsed
wrong
Package: libkmod2
Version: 9-2
Severity: important
Tags: d-i patch
This problem only affects module parameters given on the kernel command
line at boot time which include a '.' as part of their value. For
example libata.force=1.5Gbps. The bug causes such values to
overwrite the parameter, so this would get interpreted as parameter
5Gbps with no value. (force gets lost.)
To reproduce this safely, add testmodule.testparam=1.5G to the end of
the kernel command line at boot time. Then:
$ /sbin/modprobe -c |grep 5G
options testmodule 5G
This problem prevented me from using the wheezy beta 2 debian-installer
on a machine that needed libata.force=1.5Gbps to work properly with my
new SSD. See https://lists.debian.org/debian-boot/2012/10/msg00049.html
I'm including a very simple at the end of the report that fixes the
problem. Feel free to modify/edit as necessary. With this patch:
$ /sbin/modprobe -c |grep 5G
options testmodule testparam=1.5G
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-3-686-pae (SMP w/1 CPU core)
Locale: LANG=tr_TR.UTF-8, LC_CTYPE=tr_TR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libkmod2 depends on:
ii libc6 2.13-35
ii multiarch-support 2.13-35
libkmod2 recommends no packages.
libkmod2 suggests no packages.
-- no debconf information
*** kcmdline-option-parsing
Description: Fixes parsing of module parameters on the kernel command
line. Before this patch, if the parameter value had a '.' in it, that
would break things.
Author: Selim T. Erdoğan se...@alumni.cs.utexas.edu
--- kmod-9.orig/libkmod/libkmod-config.c
+++ kmod-9/libkmod/libkmod-config.c
@@ -542,6 +542,7 @@ static int kmod_config_parse_kcmdline(st
char buf[KCMD_LINE_SIZE];
int fd, err;
char *p, *modname, *param = NULL, *value = NULL;
+ int in_value_text = 0;
fd = open(/proc/cmdline, O_RDONLY|O_CLOEXEC);
if (fd 0) {
@@ -564,15 +565,20 @@ static int kmod_config_parse_kcmdline(st
*p = '\0';
kcmdline_parse_result(config, modname, param,
value);
param = value = NULL;
+ in_value_text = 0;
modname = p + 1;
break;
case '.':
- *p = '\0';
- param = p + 1;
- break;
+ if (in_value_text == 0) {
+ *p = '\0';
+ param = p + 1;
+ break;
+ }
this fall-through here doesn't seem intentional
You're correct.
case '=':
- if (param != NULL)
+ if (param != NULL) {
value = p + 1;
+ in_value_text=1;
+ }
break;
}
}
Why adding another var? Isn't something like below (whitespace
damaged) sufficient?
The version below looks good to me. (Not being familiar with how
module loading works, it took me quite some time to figure out where the
problem was: looked in the kernel, then in the debian-installer and
finally in kmod. At that point I just wanted to get a quick fix to
distinguish the two situations in which we may get a '.' and didn't
notice that param being non-NULL would be sufficient for signaling.)
Thanks a lot for debugging this. Really appreciated. At the time I
wrote this function I thought a . was not valid inside the value
param (partially because not using fp in kernel). Now I realize how
naive this assumption was and that it's even written in
Documentation/kernel-parameters.txt that we can have values with dots.
Lucas De Marchi
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674110: modprobe: ../tools/kmod-modprobe.c:550
path is NULL but the initstate of the module is BUILTIN. So maybe your
modules.dep{,bin} is corrupted?
Could you please send me the output of modprobe -
the-rest-of-your-options-here together with your modules.dep{,bin}
files?
Regards,
Lucas De Marchi
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668216: kmod: modprobe fails to load zram.ko
Thanks for the bug report. There's a patch in upstream to fix this issue: http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=patch;h=ccb64d1eade3f9f0e325ba69de586dbd4bfb8241 I'm going to release a new version by tomorrow. Regards, Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662891: kmod: Debian kernels drop to busybox prompt with
Hi, hopefully I fixed this in git. Could you try the following patch? http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=commit;h=4744ebcef48b2400d76ce5a2de735d8e74ebfe52 Marco, could you update the package? thanks Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662984: kmod: modprobe -r fails if module does not exist (Update)
I think I fixed this in git. Could you try the following patch? http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=commit;h=c1b84540bbe7aeb37f2b3384bced07cb88dbc674 thanks Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662822: kmod: modprobe -q complains about non-existent modules
I think this is fixed in -git now. Could you test the following patch? http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=commit;h=ae7ebe8770442f192a7f2f858e97f53f5c464a42 Thanks Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659838: kmod: v5 acts like a fork bomb
Hi Ingo
On Sat, Feb 18, 2012 at 9:51 PM, Ingo Saitz i...@stud.uni-hannover.de wrote:
Moin
I just got bitten by that bug today, too.
On Tue, Feb 14, 2012 at 05:05:27PM -0200, Lucas De Marchi wrote:
I bet you have these rules in your config:
install snd /sbin/modprobe --ignore-install snd { /sbin/modprobe
--quiet snd-ioctl32 ; /sbin/modprobe --quiet snd-seq ; }
...
Marco, why are you shipping this with alsa? This creates dependency
loops, relying on modules being inserted to be able to break the
loops. It seems very fragile. What are you trying to accomplish with
that config?
These are indeed useful, as it pulls in additional modules that give you
the full functionality of the sound system. The problem seems to be that
--ignore-install seems to get ignored by kmod version 5 resulting in
endless recursive loops trying to insert these modules.
It's not ignoring install commands: --ignore-install doesn't apply for
dependencies and from the description and the name of the modules what
seems to be occurring is that a module has snd as a dependency, which
is triggering the snd install command over and over again.
I prepared the patch attached... I couldn't test it (I don't have an
environment ready for this right now), but I think it fixes the issue.
Marco, I'm assuming you already backported the patch libkmod-module:
probe: fix infinite loop with softdeps, right?
Could you check if this works for you?
But since 3.12 module-init-tools (and kmod, too) supports the softdep
keyword in modprobe.d/. After changing the above rules to use softdep
instead of install, the bug was gone.
For example the rule qouted above using softdep should read:
softdep snd post: snd-ioctl32 snd-seq
I think this change could be done now in unstable, since softdep is already
supported by the module-init-tools in stable.
Yeah, you should definitely be using softdeps for this, but we still
need to support ugly old use cases.
Regards,
Lucas De Marchi
From 30549a8a2a57c9266fbe2adda9f831a2ff76a1bf Mon Sep 17 00:00:00 2001
From: Lucas De Marchi lucas.demar...@profusion.mobi
Date: Sun, 19 Feb 2012 04:20:30 -0200
Subject: [PATCH] libkmod-module: probe: check if module exists for install
cmds
Mimic what module-init-tools was doing before running install commands:
check if a module with the same name is already loaded in kerne, and if
it is, bail out.
This fixes the issue with some install commands used in Debian with
alsa-base package:
install snd /sbin/modprobe --ignore-install snd { /sbin/modprobe --quiet snd-ioctl32 ; /sbin/modprobe --quiet snd-seq ; }
install snd_rawmidi /sbin/modprobe --ignore-install snd-rawmidi { /sbin/modprobe --quiet snd-seq-midi ; : ; }
install snd_emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 { /sbin/modprobe --quiet snd-emu10k1-synth ; : ; }
install snd_pcm modprobe --ignore-install snd-pcm $CMDLINE_OPTS { modprobe --quiet snd-pcm-oss ; : ; }
install snd_mixer modprobe --ignore-install snd-mixer $CMDLINE_OPTS { modprobe --quiet snd-mixer-oss ; : ; }
install snd_seq modprobe --ignore-install snd-seq $CMDLINE_OPTS { modprobe --quiet snd-seq-midi ; modprobe --quiet snd-seq-oss ; : ; }
---
libkmod/libkmod-module.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/libkmod/libkmod-module.c b/libkmod/libkmod-module.c
index 637b792..69f1265 100644
--- a/libkmod/libkmod-module.c
+++ b/libkmod/libkmod-module.c
@@ -1192,7 +1192,17 @@ KMOD_EXPORT int kmod_module_probe_insert_module(struct kmod_module *mod,
struct kmod_module *m = l-data;
const char *moptions = kmod_module_get_options(m);
const char *cmd = kmod_module_get_install_commands(m);
- char *options = module_options_concat(moptions,
+ char *options;
+
+ if (!(flags KMOD_PROBE_IGNORE_LOADED)
+ module_is_inkernel(m)) {
+ DBG(mod-ctx, Ignoring module '%s': already loaded\n,
+m-name);
+ err = -EEXIST;
+ goto finish_module;
+ }
+
+ options = module_options_concat(moptions,
m == mod ? extra_options : NULL);
if (cmd != NULL !m-ignorecmd) {
@@ -1203,13 +1213,6 @@ KMOD_EXPORT int kmod_module_probe_insert_module(struct kmod_module *mod,
err = module_do_install_commands(m, options,
cb);
} else {
- if (!(flags KMOD_PROBE_IGNORE_LOADED)
- module_is_inkernel(m)) {
-DBG(mod-ctx, Ignoring module '%s':
- already loaded\n, m-name);
-err = -EEXIST;
-goto finish_module;
- }
if (print_action != NULL)
print_action(m, false, options ?: );
@@ -1218,9 +1221,9 @@ KMOD_EXPORT int kmod_module_probe_insert_module(struct kmod_module *mod,
options);
}
-finish_module:
free(options);
+finish_module:
/*
* Treat already loaded error. If we were told to stop on
* already loaded and the module being loaded is not a softdep
--
1.7.9.1
Bug#659838: kmod: v5 acts like a fork bomb
Hi Marco, On Sat, Feb 18, 2012 at 9:53 PM, Marco d'Itri m...@linux.it wrote: On Feb 19, Ingo Saitz i...@stud.uni-hannover.de wrote: softdep snd post: snd-ioctl32 snd-seq I think this change could be done now in unstable, since softdep is already supported by the module-init-tools in stable. Yes, kmod must be less prone to suddenly exploding and killing the system, but alsa needs to ship a modern configuration too. I agree. Please check if my patch works for you, ciao, Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659838: kmod: v5 acts like a fork bomb
Hi,
On Tue, Feb 14, 2012 at 7:03 AM, Marco d'Itri m...@linux.it wrote:
Yes, still broken.
- Forwarded message from Alban Browaeys pra...@yahoo.com -
From: Alban Browaeys pra...@yahoo.com
To: Debian Bug Tracking System sub...@bugs.debian.org
Subject: Bug#659838: kmod: v5 acts like a fork bomb
Package: kmod
Version: 5-1
Severity: important
Dear Maintainer,
The version 5 of kmod forks tenth of time to attempt to load one module.
Notwithstanding I miss the point (does anything need a module loaded 40 times
per milliseconds ?)
it render a box nearly unusable. This is with a custom kernel (I have been
workign on a few kernel
patches but currently am on vanilla). Should happens also on debian ones as
for example loading snd-hda-intel
trigger the load of snd which loads snd-seq. Here I have no snd-seq-oss (I
did not build it) so this fork
forever happens while modprobe snd-seq. But it also happens because
snd-ioctl32 is not there and
I have been unable to find this module in the i686 conf. So it might well
happens to all i386
users.
I bet you have these rules in your config:
install snd /sbin/modprobe --ignore-install snd { /sbin/modprobe
--quiet snd-ioctl32 ; /sbin/modprobe --quiet snd-seq ; }
install snd_rawmidi /sbin/modprobe --ignore-install snd-rawmidi {
/sbin/modprobe --quiet snd-seq-midi ; : ; }
install snd_emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 {
/sbin/modprobe --quiet snd-emu10k1-synth ; : ; }
install snd_pcm modprobe --ignore-install snd-pcm $CMDLINE_OPTS {
modprobe --quiet snd-pcm-oss ; : ; }
install snd_mixer modprobe --ignore-install snd-mixer $CMDLINE_OPTS
{ modprobe --quiet snd-mixer-oss ; : ; }
install snd_seq modprobe --ignore-install snd-seq $CMDLINE_OPTS {
modprobe --quiet snd-seq-midi ; modprobe --quiet snd-seq-oss ; : ; }
Marco, why are you shipping this with alsa? This creates dependency
loops, relying on modules being inserted to be able to break the
loops. It seems very fragile. What are you trying to accomplish with
that config? Looking at
http://packages.debian.org/sid/all/alsa-base/filelist, it seems like
you still have the file where these configs come from. I'm adding
Jordi and Elimar in CC, since they are the package maintainers in
Debian.
Reverting to libkmod1 and kmod 3-1 fixed the issue. I now get Fatal: Module
snd-seq-oss messages but no
more fork bombs.
In kmod-5 we changed the way we calculate dependencies to be faster,
more reliable and share code between modprobe and libkmod. Sadly as a
result this regression appeared. We also added a testsuite, so if
anyone write a test for this case we can make sure this regression
doesn't appear anymore.
I'll take a look how to fix this up, but please could you drop that
config or explain what are their goals?
Regards
Lucas De Marchi
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656683: [matteo...@member.fsf.org: Re: Bug#656683: kmod: Switching to kmod makes only one ATI driver between audio and video work]
Hi Marco and Matteo On Mon, Jan 23, 2012 at 12:57 PM, Marco d'Itri m...@linux.it wrote: You can just answer to the attached message. -- ciao, Marco -- Forwarded message -- From: Matteo Settenvini matteo...@member.fsf.org To: Marco d'Itri m...@linux.it Cc: 656...@bugs.debian.org Date: Mon, 23 Jan 2012 15:56:18 +0100 Subject: Re: Bug#656683: kmod: Switching to kmod makes only one ATI driver between audio and video work Il giorno lun, 23/01/2012 alle 14.58 +0100, Marco d'Itri ha scritto: - Forwarded message from Lucas De Marchi lucas.demar...@profusion.mobi - From: Lucas De Marchi lucas.demar...@profusion.mobi To: m...@linux.it Cc: linux-modules linux-modu...@vger.kernel.org Subject: modprobe eating all memory 3. boot with init=/bin/bash in kernel cmdline 4. try to load each module to see what module is failing (pass - to modprobe in order to get debug info). 5. send the output for the failing module together with the output for modprobe -c Okay Marco and Lucas, I went through the drill, and followed the steps. It would appear there is something strange happening when loading the sound drivers. Attached you will find the two requested logs. modprobe.log contains the log when trying to load the snd_hda_codec module. There is a FATAL line saying Module snd-ioctl32 not found., however I don't know if it is the issue.] It just means that you have a bogus line in your configuration. There's no snd-ioctl32 module in your system. The main point is that it gets in a loop, and eats away more and more memory. I had to reboot after a while (^C wouldn't work), so the log might be truncated at a certain point; however you can see it repeats itself. Ok, I found the problem. modprobe is trying to load module's dependencies even if it is an install command and not a real module. modprobe-c.txt contains, predictably, the output of modprobe -c. What a huge amount of the install commands Why do you need all those? I'll fix kmod, but you should start using softdeps instead of using install commands to create dependencies. Thanks for reporting this bug. Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656683: kmod: Switching to kmod makes only one ATI driver between audio and video work
Hi Matteo, On Mon, Jan 23, 2012 at 4:53 PM, Matteo Settenvini matteo...@member.fsf.org wrote: I can confirm that kmod4 works correctly when commenting out those install lines in alsa-base.conf. I commented out everything and I see no regression insofar. Indeed, that install lines are just insane. I'm providing a fix that will hit kmod's git eventually. Regards, Lucas De Marchi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
