[Bug 111918] Kernel tainted even when given option is unsupported, with an incorrect taint flag

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=111918

--- Comment #7 from Joonas Lahtinen <joonas.lahtinen at linux.intel.com> ---
If an unsafe module parameter is set (like you have enable_guc), the bugs
should not be reported to upstream Bugzilla. That's the right signal to give to
the user, regardless if the kernel was succesfully able to load all the
firmwares or not for that specific boot. The kernel triggers an unsupported
codepath when you enable the option.

That modparam checking code is not from i915, we're just using what core kernel
provides at kernel/params.c. So the discussion would have to be at core kernel
level. And I think it might be hard sell to skip tainting the kernel when the
unsafe modparams don't have an effect. Not least because it's hard to define
what is to have an effect, as in your case two NOTICE level messages get
printed to the dmesg. That would already be picked up by many tools set up to
monitor the dmesg.

That'd be a lot of work just to support a special case when the user happens to
have unsafe module parameters at cmdline which don't happen to activate on that
specific boot. Whereas the user should not have any unsafe module parameters on
the cmdline to begin with, and the problem can be removed by removing the
cmdline option.

And finally, I think the rationale behind adding user taint for user supplied
cmdline parameter makes much sense. The documentation could be fixed to reflect
that cmdline is a possible origin of the user taint? I'm sure a such patch
would get accepted to core kernel.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20191009/86e759a3/attachment.html>