Re: [PATCH] [RFC] Taint the kernel for unsafe module options

[Daniel Vetter]

On Wed, Mar 5, 2014 at 10:00 PM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote:
> On Wed, Mar 5, 2014 at 9:32 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>> On Wed,  5 Mar 2014 10:33:14 +0100 Daniel Vetter <daniel.vetter@xxxxxxxx> wrote:
>>
>>> Users just love to set random piles of options since surely enabling
>>> all the experimental stuff helps. Later on we get bug reports because
>>> it all fell apart.
>>>
>>> Even more fun when it's labelled a regression when some change only
>>> just made the feature possible (e.g. stolen memory fixes suddenly
>>> making fbc possible).
>>>
>>> Make it clear that users are playing with fire here. In drm/i915 all
>>> these options follow the same pattern of using -1 as the per-machine
>>> default, and any other value being used for force the parameter.
>>>
>>> Adding a pile of cc's to solicit input and figure out whether this
>>> would be generally useful - this quick rfc is just for drm/i915.
>>
>> Seems harmless and potentially useful to others so yes, I'd vote for
>> putting it in core kernel.
>>
>> However this only handles integers.  Will we end up needed great gobs
>> of new code to detect unsafe setting of u8's, strings, etc?
>
> Well I've just done integers because hardcoding the -1 default was so
> easy ... But thinking about it some more (and looking at some more mod
> params in i915) passing the default to the macro and storing it in
> some struct, together with the pointer for the variable sounds useful.
> With that this could be easily extended to all kinds of types.
>
> Now would such a temporary structure to store the default be
> acceptable or is there some neater trick to pull this off?

s/temporary/created by the macro/ ... past beer time here already ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/