Re: modprobe: Cannot load blacklisted module by symbol

Re: modprobe: Cannot load blacklisted module by symbol

[Lucas De Marchi]

Hi David,

On Thu, May 23, 2013 at 2:38 PM, David Henningsson
<david.henningsson@canonical.com> wrote:
> Hi Lucas,
>
> I'm not sure if you're the right person to contact, if not, feel free to
> redirect me.

Yes, but make sure to CC the mailing list (done now).

>
> While debugging and testing some other code, we were trying to use the
> kernel symbol_request() call. This does not work if the module to be loaded
> is blacklisted, whereas module_request() for the same module succeeds.
> E g, when "i915" is blacklisted, loading "i915" still succeeds, but not
> "symbol:i915_gpu_busy".
>
> I think I've traced this down to this commit [1]. Is this expected
> behaviour? We certainly did not expect it.

Yes, that's because blacklist doesn't apply to the module names,
unless "-b" is given (which I would expect to be the normal behavior,
but this inherited from module-init-tools).

Since symbol:i915_gpu_busy is treated as an alias, the blacklist
applies for this one though.

Why do you want to load i915 by symbol if it's blacklisted?

Lucas De Marchi

Re: modprobe: Cannot load blacklisted module by symbol

[Takashi Iwai]

At Thu, 23 May 2013 15:13:16 -0300,
Lucas De Marchi wrote:
> 
> Hi David,
> 
> On Thu, May 23, 2013 at 2:38 PM, David Henningsson
> <david.henningsson@canonical.com> wrote:
> > Hi Lucas,
> >
> > I'm not sure if you're the right person to contact, if not, feel free to
> > redirect me.
> 
> Yes, but make sure to CC the mailing list (done now).
> 
> >
> > While debugging and testing some other code, we were trying to use the
> > kernel symbol_request() call. This does not work if the module to be loaded
> > is blacklisted, whereas module_request() for the same module succeeds.
> > E g, when "i915" is blacklisted, loading "i915" still succeeds, but not
> > "symbol:i915_gpu_busy".
> >
> > I think I've traced this down to this commit [1]. Is this expected
> > behaviour? We certainly did not expect it.
> 
> Yes, that's because blacklist doesn't apply to the module names,
> unless "-b" is given (which I would expect to be the normal behavior,
> but this inherited from module-init-tools).
> 
> Since symbol:i915_gpu_busy is treated as an alias, the blacklist
> applies for this one though.
> 
> Why do you want to load i915 by symbol if it's blacklisted?

We're trying to implement the dynamic binding of i915 symbol to be
called from HD-audio driver.  The call of i915 function is needed for
controlling the i915 graphics power well feature which also influences
on the HDMI audio (that is over the graphics, after all).

The dynamic binding was proposed so that we don't have to introduce a
strict dependency to snd-hda-intel module on i915, since the audio
driver is used generically for all HD-audio hardware, not only for
Intel but for AMD or whatever.  Obviously non-Intel hardware don't
want to load i915 module.

Now, the question is which behavior is _more_ correct.

A: If i915 module is blacklisted, it can be seen as an undesired
   driver, so we should refuse the corresponding audio device, too.

B: Even if i915 module is blacklisted, we should load it when a module
   depending on it is loaded.

If the dependency between modules is explicit, currently it behaves
like B.  E.g. even if the module "drm" is blacklisted, it'll be loaded
forcibly if you load the module "i915".  So, from the POV, the
implicit dependency should behave like B.

OTOH, in the case of HD-audio HDMI audio, the option A makes also
sense.  User doesn't want to i915 video, so the HDMI audio shouldn't
be used, too.

So, if I would have to choose, I'd select A.  But it's not strong
opinion at all, and I'd like to hear others.


thanks,

Takashi

Re: modprobe: Cannot load blacklisted module by symbol

[David Henningsson]

On 05/23/2013 08:13 PM, Lucas De Marchi wrote:
> Hi David,
>
> On Thu, May 23, 2013 at 2:38 PM, David Henningsson
> <david.henningsson@canonical.com> wrote:
>> Hi Lucas,
>>
>> I'm not sure if you're the right person to contact, if not, feel free to
>> redirect me.
>
> Yes, but make sure to CC the mailing list (done now).

Ok, thanks. I tried to find references to a mailing list in the code 
(README etc) but didn't find any.

>> While debugging and testing some other code, we were trying to use the
>> kernel symbol_request() call. This does not work if the module to be loaded
>> is blacklisted, whereas module_request() for the same module succeeds.
>> E g, when "i915" is blacklisted, loading "i915" still succeeds, but not
>> "symbol:i915_gpu_busy".
>>
>> I think I've traced this down to this commit [1]. Is this expected
>> behaviour? We certainly did not expect it.
>
> Yes, that's because blacklist doesn't apply to the module names,
> unless "-b" is given (which I would expect to be the normal behavior,
> but this inherited from module-init-tools).
>
> Since symbol:i915_gpu_busy is treated as an alias, the blacklist
> applies for this one though.
>
> Why do you want to load i915 by symbol if it's blacklisted?

The example is a bit contrived, but it was to test our module loading 
code: without blacklisting, i915 would always load before the module 
that was supposed to load it (snd-hda-intel), and so blacklisting was 
our way of making sure snd-hda-intel was loaded first, so we could test 
that the module loading worked.

What bothers me is the inconsistency though: either blacklisting 
applies, and then it should apply to both names, aliases, symbols etc.
Or blacklisting does not apply, and then it should not apply to either 
names, aliases nor symbols.

Is this inconsistency also inherited from module-init-tools?

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: modprobe: Cannot load blacklisted module by symbol

[Lucas De Marchi]

On Fri, May 24, 2013 at 8:35 AM, David Henningsson
<david.henningsson@canonical.com> wrote:
> On 05/23/2013 08:13 PM, Lucas De Marchi wrote:
>>
>> Hi David,
>>
>> On Thu, May 23, 2013 at 2:38 PM, David Henningsson
>> <david.henningsson@canonical.com> wrote:
>>>
>>> Hi Lucas,
>>>
>>> I'm not sure if you're the right person to contact, if not, feel free to
>>> redirect me.
>>
>>
>> Yes, but make sure to CC the mailing list (done now).
>
>
> Ok, thanks. I tried to find references to a mailing list in the code (README
> etc) but didn't find any.
>
>
>>> While debugging and testing some other code, we were trying to use the
>>> kernel symbol_request() call. This does not work if the module to be
>>> loaded
>>> is blacklisted, whereas module_request() for the same module succeeds.
>>> E g, when "i915" is blacklisted, loading "i915" still succeeds, but not
>>> "symbol:i915_gpu_busy".
>>>
>>> I think I've traced this down to this commit [1]. Is this expected
>>> behaviour? We certainly did not expect it.
>>
>>
>> Yes, that's because blacklist doesn't apply to the module names,
>> unless "-b" is given (which I would expect to be the normal behavior,
>> but this inherited from module-init-tools).
>>
>> Since symbol:i915_gpu_busy is treated as an alias, the blacklist
>> applies for this one though.
>>
>> Why do you want to load i915 by symbol if it's blacklisted?
>
>
> The example is a bit contrived, but it was to test our module loading code:
> without blacklisting, i915 would always load before the module that was
> supposed to load it (snd-hda-intel), and so blacklisting was our way of
> making sure snd-hda-intel was loaded first, so we could test that the module
> loading worked.
>
> What bothers me is the inconsistency though: either blacklisting applies,
> and then it should apply to both names, aliases, symbols etc.

This is the case when calling modprobe with -b option. For example,
udev uses it.

> Or blacklisting does not apply, and then it should not apply to either
> names, aliases nor symbols.

I agree.

>
> Is this inconsistency also inherited from module-init-tools?

Yes, it's like this only because modprobe from module-init-tools had
this behavior. I don't think we can change this without breaking
others.

What we could do is to create a "more modern" tool and put the options
and behaviors we are expecting now. This is what I am doing for "kmod
load" but this depends on the effort to allow the kernel to call
another tool instead of modprobe [1]. However in this front we also
have incompatibilities with previous behavior :-(

Lucas De Marchi

[1] https://lkml.org/lkml/2013/5/10/3