linux-kernel - Re: udev 182: response timeout for request_firmware in module

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]

Date:	Thu, 23 Aug 2012 23:16:46 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Johannes Berg <johannes@...solutions.net>,
	Larry Finger <Larry.Finger@...inger.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	systemd-devel@...ts.freedesktop.org
Subject: Re: udev 182: response timeout for request_firmware in module_probe path

Cc systemd-devel

Hi,

On Tue, Aug 21, 2012 at 1:34 PM, Ming Lei <tom.leiming@...il.com> wrote:
> Hi Kay,
>
> I found that udev 182 doesn't response for the request_firmware in
> module_probe path until 30sec later after the 'ADD' event of firmware
> device, but no such problem in udev175, sounds like a regression of udev?

Looks udevd is capable of handling the firmware ADD event even though
the device ADD event is being processed( modprobe is triggered by device
ADD event).

The below patch[1] can fix the problem, could you give any comments on it？

>
> I find there was a related discussion in [1], so CC guys who discussed before.
>
> Just grep under kernel root dir, there are about 360 request_firmware callers,
> and looks most of them are called in .probe path.
>
>
> [1], https://lkml.org/lkml/2012/2/19/57


[1],

diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index b4fc624..806721c 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -96,6 +96,7 @@ struct event {
         const char *devpath_old;
         dev_t devnum;
         bool is_block;
+        bool is_firmware;
         int ifindex;
 };

@@ -439,6 +440,7 @@ static int event_queue_insert(struct udev_device *dev)
         event->devpath_old = udev_device_get_devpath_old(dev);
         event->devnum = udev_device_get_devnum(dev);
         event->is_block = (strcmp("block",
udev_device_get_subsystem(dev)) == 0);
+        event->is_firmware = (strcmp("firmware",
udev_device_get_subsystem(dev)) == 0);
         event->ifindex = udev_device_get_ifindex(dev);

         udev_queue_export_device_queued(udev_queue_export, dev);
@@ -520,7 +522,7 @@ static bool is_devpath_busy(struct event *event)
                 }

                 /* parent device event found */
-                if (event->devpath[common] == '/') {
+                if (event->devpath[common] == '/' && !event->is_firmware) {
                         event->delaying_seqnum = loop_event->seqnum;
                         return true;
                 }



Thanks,
-- 
Ming Lei
--
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/