On Fri, 03 Aug 2007 21:07:35 +0200
Javier Pello <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
