Message-ID: <20171204135829.ubgthj4pq6f77pbj@redbean>
Date:   Mon, 4 Dec 2017 14:58:30 +0100
From:   Jessica Yu <jeyu@...nel.org>
To:     Djalal Harouni <tixxdz@...il.com>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Jessica Yu <jeyu@...hat.com>,
        Rusty Russell <rusty@...tcorp.com.au>,
        Kees Cook <keescook@...omium.org>, mbenes@...e.cz,
        atomlin@...hat.com, Petr Mladek <pmladek@...e.com>, hare@...e.com,
        James Morris <james.l.morris@...cle.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "David S . Miller" <davem@...emloft.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: module: add debugging alias parsing support

+++ Djalal Harouni [04/12/17 10:01 +0100]:
>On Thu, Nov 30, 2017 at 7:39 PM, Luis R. Rodriguez <mcgrof@...nel.org> wrote:
>> On Thu, Nov 30, 2017 at 02:17:11PM +0100, Jessica Yu wrote:
>>> Just some quick questions - are there any plans to use these in-kernel
>>> module aliases anywhere else? Or are you using them just for debugging?
>>
>> As-is for now just debugging, but this could also more easily enable folks to
>> prototype further evaluation of its uses. IMHO just having this at least posted
>> online should suffice the later aspect of enabling folks to prototype.
>
>I confirm that, after the module auto-load discussion where it is
>clear that we need to improve the infrastructure, this debug
>information may save some time, maybe someone can automate a script go
>through modules and then on filesystem,

>however these patches may show
>which module lead to load another one, right ? on userspace if there
>are multiple dependencies it can be difficult I think.

Hm? I'm confused by what you mean here. The patchset just saves and
prints a module's aliases on module load if the debug option is
enabled. There's no dependency tracking here; that's modprobe's job.
And if you need to see which additional modules are being loaded as a
result of a module load there's already modprobe --verbose and
modules.dep..

>> You're right that one can find aliases in userspace. One of the benefits
>> of having this dump things on the kernel log is just that you can easily
>> get the aliases printed out for all modules actually loaded for your system
>> without much effort. I did find this useful when debugging and found it much
>> more convenient than scraping modules one by one by hand in userspace.
>>
>> I had this implemented since 2016, and I had some ideas to use them in a
>> functional way, however I first had to knock out a series of of fixes for
>> kernel/kmod.c and setting up a baseline test infrastructure for kmod
>> (tools/testing/selftests/kmod/ and lib/test_kmod.c) as such I hadn't had time
>> to yet come around and finish benchmarking the alias enhancement ideas I had
>> started evaluating.
>>
>> As such having aliases in-kernel currently are only useful for debugging and
>> prototyping.
>
>I would say so, however no strong argument if it should be mainlined.
>Luis in your commit log you say:
>
>"Obviously userspace can be buggy though, and it can lie to us. We
>currently have no easy way to determine this."
>
>Could you please share some info here ? how userspace can be buggy ?

Ditto, I agree that a concrete debugging example would be helpful in
understanding why having this in-kernel is better than using existing
userspace tools to look up module aliases. AFAIK the debug prints only
on module load, but you could also easily get the aliases for all
modules loaded on your system by doing something like -

for mod in $(awk '{print $1}' /proc/modules) ; do echo $mod; modinfo -F alias $mod ; done

(Assuming they are all modules that modprobe knows about) Is there a
debugging scenario you ran into where the above script wouldn't
suffice?

Jessica

Powered by blists - more mailing lists