GNU bug report logs - #30604
[PATCH 0/4] Load Linux module only when supported hardware is present.

Previous Next

Package: guix-patches;

Reported by: Danny Milosavljevic <dannym <at> scratchpost.org>

Date: Sun, 25 Feb 2018 11:47:02 UTC

Severity: important

Tags: patch

Full log


Message #368 received at 30604 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 30604 <at> debbugs.gnu.org
Subject: Re: [bug#30604] [PATCH v10 5/6] linux-initrd: Provide our own
 'modprobe' program.
Date: Tue, 13 Mar 2018 10:27:06 +0100
[Message part 1 (text/plain, inline)]
Hi Ludo,

On Mon, 12 Mar 2018 23:14:59 +0100
ludo <at> gnu.org (Ludovic Courtès) wrote:

> > One of the devnames created statically is the one for btrfs, so not writing or
> > using devnames is not going to end well.  
> 
> We’re fine because btrfs, 9p, overlay, etc. all have an “fs-btrfs”,
> “fs-9p”, etc. alias, which shows up in “modules.alias”.  No need for
> “modules.devname” AFAICS.

The other filesystems are not such a problem - but BTRFS has its own snapshotting/
multivolume functionality - and it's possible that someone accesses /dev/btrfs-control
"too early" for that.

I applied your patches to a fresh clone of guix master now, ran the btrfs-root-os
system check, and indeed I get (tried two rounds, happened both times):

$ make TESTS=btrfs-root-os check-system
[...]
Scanning for Btrfs filesystems
WARNING: failed to open /dev/btrfs-control, skipping device registration: No suy
ERROR: there are 1 errors while registering devices
File system check on /dev/vda2 failed; spawning Bourne-like REPL
GNU Guile 2.2.3
Copyright (C) 1995-2017 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
(can't evaluate anything here)

> > (I'd also copy the modules.builtin (from Linux).
> >  Also, what happens if we load a module which has as dependency a builtin?
> >  Will we try to load the builtin as a .ko file and fail the entire thing?)  
> 
> The dependency of a builtin is necessarily a builtin, 

Yes.

>and the kernel won’t invoke modprobe for a builtin, will it?  

I've read Linux's __request_module and I can't find where they
pre-check anything - neither whether there's already a builtin
nor whether it's loaded already.

They probably don't check.  But I'll read it again, more carefully...

(request_module isn't that popular so it makes sense for them not to complicate
the kernel by these checks when there are like 8 callers in total - and all on init)

>Thanks for the insightful review!

You're welcome :)
[Message part 2 (application/pgp-signature, inline)]

This bug report was last modified 5 years and 305 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.