linux-kernel - Re: [PATCH] modules: add support for soft module dependencies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87zjray4y1.fsf@rustcorp.com.au>
Date:	Wed, 18 Sep 2013 16:47:10 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Lucas De Marchi <lucas.demarchi@...fusion.mobi>
Cc:	Lucas De Marchi <lucas.de.marchi@...il.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Andreas Robinson <andr345@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Zhao Hongjiang <zhaohongjiang@...wei.com>,
	David Miller <davem@...emloft.net>, tim.c.chen@...ux.intel.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	"gregkh\@linuxfoundation.org" <gregkh@...uxfoundation.org>,
	linux-crypto@...r.kernel.org,
	linux-modules <linux-modules@...r.kernel.org>,
	Tom Gundersen <teg@...m.no>
Subject: Re: [PATCH] modules: add support for soft module dependencies

Lucas De Marchi <lucas.demarchi@...fusion.mobi> writes:
> On Tue, Sep 17, 2013 at 11:10 PM, Rusty Russell <rusty@...tcorp.com.au> wrote:
>> Lucas De Marchi <lucas.de.marchi@...il.com> writes:
>>> On Thu, Sep 12, 2013 at 9:07 PM, Rusty Russell <rusty@...tcorp.com.au> wrote:
>>>> I'm happy to change this macro to create a modinfo line like
>>>> "softdep:<modname>"
>>>
>>> how is that solving the issue that this macro can be used to designate
>>> a mandatory or optional dependency
>>> (https://lkml.org/lkml/2013/9/10/371)? If we decide the dependency is
>>> mandatory we can very well let modprobe use that dependency during
>>> module load
>>
>> I'm very close to sending Linus a revert commit at this point, since
>> there's no consensus on what it's for.
>>
>> *Clearly* softdep shouldn't indicate a mandatory dependency.  We already
>> have a way (several) to make mandatory dependencies!
>>
>> And the "pre:" vs "post:" thing is just weird.  If a module wants a post
>> dependency, you can request_module() it from a workqueue.
>>
>>>> ie. tools like mkinitrd could pick it up and try to find a matching
>>>> module, but depmod would ignore it.
>>>
>>> Some mkinitrd-like use whatever depmod/modprobe tells them it's
>>> needed. So kmod still needs to know about it.
>>
>> It sounds like we should create a separate tool, which takes a list of
>> modules and spits out the full pathname of all dependencies.  *That*
>> tool should include soft dependencies.
>>
>>>> It's really up to Lucas, since this affects him.
>>>
>>> IMO  saying "this is an optional dependency and we can work without"
>>> doesn't buy us much. Distros will end up putting the soft dep in
>>> /etc/modules.d, kmod will always use them anyway and failing to load
>>> the soft dep will fail the module load. I'd like to have no distro
>>> files in /etc/modules.d in future.
>>
>> I assumed modprobe would handle soft dependencies in modules and try to
>> pull them in, but *not* fail if they don't work.
>
> Iff the module doesn't *exist*. If it failed to load or failed for any
> other reason then we will abort trying to load the other module.
> However this is one thing we can change in modprobe to make it
> consistent and more predictable. But we really need to reach a
> consensus.

It is a bit of a corner case, but there are other conceivable reasons
why a module wouldn't load.  The hardware it wants might not be present,
or busy, or it conflicts with an existing module, or needs user
configuration (eg. commandline params).

It might be worth reporting, but I wouldn't stop loading on softdep fails.

>> The previous way of doing this was:
>>         install foo modprobe foo_softdep 2>/dev/null; modprobe --ignore-install foo $CMDLINE_OPTS
>
> I just hope this is in no way an incentive for people using install commands ;-)

Agreed.  install commands were implemented because I had no idea what
people wanted to do in future.  They definitely provide enough rope...

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/