On 9/4/26 2:19 PM, Greg Kroah-Hartman wrote: > On Fri, Sep 04, 2026 at 11:25:01AM +0200, Petr Pavlu wrote: >> On 9/4/26 7:10 AM, Greg Kroah-Hartman wrote: >>> diff --git a/kernel/module/main.c b/kernel/module/main.c >>> index d0e1e0bd2ad0..444d990c9983 100644 >>> --- a/kernel/module/main.c >>> +++ b/kernel/module/main.c >>> @@ -191,11 +191,21 @@ static inline int strong_try_module_get(struct module >>> *mod) >>> return -ENOENT; >>> } >>> >>> -static inline void add_taint_module(struct module *mod, unsigned flag, >>> - enum lockdep_ok lockdep_ok) >>> +/** >>> + * add_taint_module: add a taint flag if not already set for a specific >>> module >>> + * @mod: pointer to the module that caused the problem >>> + * @flag: one of the TAINT_* constants. >>> + * @lockdep_ok: whether lock debugging is still OK. >>> + * >>> + * If something bad has gone wrong, you'll want @lockdebug_ok = false, but >>> for >>> + * some noteworthy-but-not-corrupting cases, it can be set to true. >> >> Nit: The final paragraph is mostly copied from the description of >> add_taint() but I don't think it is quite right. The parameter name >> should be lockdep_ok, not lockdebug_ok and the values are >> LOCKDEP_STILL_OK / LOCKDEP_NOW_UNRELIABLE, not true / false. >> >> I suggest updating this part for both add_taint() and add_taint_module() >> to something like: >> >> * Use @lockdep_ok = LOCKDEP_NOW_UNRELIABLE if something serious has gone >> wrong. >> * For noteworthy but non-corrupting cases, use LOCKDEP_STILL_OK instead. > > How about I add another patch to the series that fixes up the > documentation for both functions? They both should be fixed up and I > might as well get them in sync properly.
Makes sense to me. -- Thanks, Petr
