linux-kernel - Re: [PATCH] request_firmware: skip timeout if userspace was not notified

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070807130502.615d0112.akpm@linux-foundation.org>
Date:	Tue, 7 Aug 2007 13:05:02 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Javier Pello <javier.pello@...c.es>
Cc:	linux-kernel@...r.kernel.org, Greg KH <greg@...ah.com>
Subject: Re: [PATCH] request_firmware: skip timeout if userspace was not 
 notified

On Fri, 03 Aug 2007 21:07:35 +0200
Javier Pello <javier.pello@...c.es> wrote:

> Hi,
> 
> I have prepared a patch that makes request_firmware skip the usual
> grace period that it gives firmware images to show up, if it determines
> that userspace was not notified at all.
> 
> When request_firmware is called, it sends an event to userspace to
> ask for the firmware image that is needed, and then it installs a
> timeout so that it will not wait forever for the image. However,
> if userspace did not receive the event at all (no /sbin/hotplug,
> for instance), then having the kernel wait is pointless. This is
> particularly true during boot, when the wait is done synchronously
> and the whole kernel freezes for a minute.
> 
> The attached patch fixes this by making _request_firmware check whether
> the firmware loading event was succesfully sent to userspace, and skip
> the timeout if it has not. The patch comes in two parts:
> 
> 1. The first part changes kobject_uevent_env in lib/kobject_uevent.c
> to report a failure if both netlink_broadcast (if applicable) and
> call_usermodehelper fail to send the event to userspace. Nothing in
> the kernel seems to care about the return value of kobject_uevent_env,
> so this should not break anything.
> 
> 2. The second part changes _request_firmware in
> drivers/base/firmware_class.c to actually check the return value of
> kobject_uevent and skip the loading_timeout delay if the loading event
> was not delivered to userspace at all.
> 
> The patches apply cleanly against 2.6.23-rc1. Any suggestions or feedback
> will be welcome.
> 
> ---
> diff -u linux-2.6.22/lib/kobject_uevent.c linux-2.6.22-p/lib/kobject_uevent.c
> --- linux-2.6.22/lib/kobject_uevent.c	2007-07-09 01:32:17.000000000 +0200
> +++ linux-2.6.22-p/lib/kobject_uevent.c	2007-07-18 20:17:10.000000000 +0200
> @@ -186,7 +186,8 @@
>  			}
>  
>  			NETLINK_CB(skb).dst_group = 1;
> -			netlink_broadcast(uevent_sock, skb, 0, 1, GFP_KERNEL);
> +			retval = netlink_broadcast(uevent_sock, skb, 0, 1,
> +						GFP_KERNEL);
>  		}
>  	}
>  #endif
> @@ -198,7 +199,18 @@
>  		argv [0] = uevent_helper;
>  		argv [1] = (char *)subsystem;
>  		argv [2] = NULL;
> -		call_usermodehelper (argv[0], argv, envp, UMH_WAIT_EXEC);
> +#if defined(CONFIG_NET)
> +		if (retval) {
> +			retval = call_usermodehelper (argv[0], argv, envp,
> +						UMH_WAIT_EXEC);
> +		} else {
> +			call_usermodehelper (argv[0], argv, envp,
> +						UMH_WAIT_EXEC);
> +		}
> +#else
> +		retval = call_usermodehelper (argv[0], argv, envp,
> +						UMH_WAIT_EXEC);
> +#endif
>  	}
>  
>  exit:

If uevent_helper[0] is \0 then this function can return success, even
though it didn't deliver anything to userspace.

I suppose that's correct behaviour: the operator configured the system to
disable the hotplug callout.  However in this scenario, the firmware laoder
will still needlessly implement the grace period.

It's probably not worth worrying about.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/