Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Low] The newly introduced `module_denylist` kernel parameter is not documented in `kernel-parameters.txt`, and the legacy parameter is not marked as deprecated. - [Low] Kernel log messages were not updated to reflect the new inclusive terminology. --
--- Patch [2]: [PATCH v5 2/2] module: Rename module_blacklist to module_denylist --- commit 4cda93857ba5a82c96224a9d0d2d74dde6f4849f Author: Aaron Tomlin <[email protected]> module: Rename module_blacklist to module_denylist This commit renames the internal module_blacklist variables and helper functions to module_denylist to align with the kernel's coding style guide. It retains module_blacklist as a legacy alias for backward compatibility. > To align with the kernel's established coding style guide regarding > naming conventions (i.e., Documentation/process/coding-style.rst), > migrate the internal module_blacklist variables and helper functions to > module_denylist and module_is_denylisted(). [Severity: Low] Since the kernel parameter is being updated to module_denylist=, should Documentation/admin-guide/kernel-parameters.txt also be updated to document the new parameter and mark the old module_blacklist parameter as deprecated? > diff --git a/init/main.c b/init/main.c > index 7899a31d525df..df21df7b7e868 100644 > --- a/init/main.c > +++ b/init/main.c [ ... ] > @@ -1408,9 +1409,9 @@ int __init_or_module do_one_initcall(initcall_t fn) > const char *modname = NULL; > int ret; > > - if (system_state < SYSTEM_FREEING_INITMEM && module_blacklist) { > + if (system_state < SYSTEM_FREEING_INITMEM && module_denylist) { > modname = get_builtin_modname(fn); > - if (modname && module_is_blacklisted(modname)) { > + if (modname && module_is_denylisted(modname)) { > pr_info("Skipping initcall for blacklisted built-in > module %s\n", > modname); [Severity: Low] This isn't a bug, but should the pr_info() log message also be updated to say "denylisted" instead of "blacklisted" to match the new terminology? > return 0; [ ... ] > diff --git a/kernel/module/main.c b/kernel/module/main.c > index d397b57f57b65..0f05497c0fc3e 100644 > --- a/kernel/module/main.c > +++ b/kernel/module/main.c [ ... ] > @@ -3298,9 +3298,9 @@ static int early_mod_check(struct load_info *info, int > flags) > > /* > * Now that we know we have the correct module name, check > - * if it's blacklisted. > + * if it's denylisted. > */ > - if (module_is_blacklisted(info->name)) { > + if (module_is_denylisted(info->name)) { > pr_err("Module %s is blacklisted\n", info->name); [Severity: Low] This isn't a bug, but should this pr_err() message also be updated to use "denylisted" to fully align with the naming convention update? > return -EPERM; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
