modprobe: Cannot load blacklisted module by symbol

[Lucas De Marchi]

Hi David,

On Thu, May 23, 2013 at 2:38 PM, David Henningsson

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

[Takashi Iwai]

At Thu, 23 May 2013 15:13:16 -0300,

Post by Lucas De Marchi
Hi David,
On Thu, May 23, 2013 at 2:38 PM, David Henningsson

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

[David Henningsson]

Post by Lucas De Marchi
Hi David,
On Thu, May 23, 2013 at 2:38 PM, David Henningsson

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.

Post by Lucas De Marchi

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?

[Lucas De Marchi]

On Fri, May 24, 2013 at 8:35 AM, David Henningsson

Post by Lucas De Marchi
Hi David,
On Thu, May 23, 2013 at 2:38 PM, David Henningsson

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.

Post by Lucas De Marchi

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?

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