Oleg Nesterov <o...@redhat.com> writes:
> call_usermodehelper_exec() does nothing but returns success if
> path[0] == 0. The only user which needs this strange feature is
> request_module(), it can check modprobe_path[0] itself like other
> users do if they want to detect the "disabled by admin" case.
>
> Kill it. Not only it looks strange, it can confuse other callers.
> And this allows us to revert 264b83c0 "usermodehelper: check
> subprocess_info->path != NULL", do_execve(NULL) is safe.
>
> Signed-off-by: Oleg Nesterov <o...@redhat.com>
Nice cleanup. It was definitely weird...
Acked-by: Rusty Russell <ru...@rustcorp.com.au>
Thanks!
Rusty.
> ---
> kernel/kmod.c | 11 +++--------
> 1 files changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index 8241906..fb32636 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -147,6 +147,9 @@ int __request_module(bool wait, const char *fmt, ...)
> */
> WARN_ON_ONCE(wait && current_is_async());
>
> + if (!modprobe_path[0])
> + return 0;
> +
> va_start(args, fmt);
> ret = vsnprintf(module_name, MODULE_NAME_LEN, fmt, args);
> va_end(args);
> @@ -569,14 +572,6 @@ int call_usermodehelper_exec(struct subprocess_info
> *sub_info, int wait)
> int retval = 0;
>
> helper_lock();
> - if (!sub_info->path) {
> - retval = -EINVAL;
> - goto out;
> - }
> -
> - if (sub_info->path[0] == '\0')
> - goto out;
> -
> if (!khelper_wq || usermodehelper_disabled) {
> retval = -EBUSY;
> goto out;
> --
> 1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
