Re: [PATCH v5 2/2] module: Rename module_blacklist to module_denylist

[sashiko-bot@kernel.org]

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 <atomlin@atomlin.com>

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/20260718051350.344772-1-atomlin@atomlin.com?part=2