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]

Message-ID: <CACVXFVMFKGPv9Am0KzKSVsRamcA8EMMnD0kQO40MJ6OsjK4Eow@mail.gmail.com>
Date:	Fri, 24 Aug 2012 00:04:32 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Kay Sievers <kay@...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

On Thu, Aug 23, 2012 at 11:31 PM, Kay Sievers <kay@...y.org> wrote:
> On Thu, Aug 23, 2012 at 5:16 PM, Ming Lei <tom.leiming@...il.com> wrote:
>> On Tue, Aug 21, 2012 at 1:34 PM, Ming Lei <tom.leiming@...il.com> wrote:
>
>>> 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).
>
> Calling out from inside the kernel and blocking in a firmware loading
> userspace transaction during module_init() is kind of weird.

Strictly speaking, the request_firmware is not called by module_init()
directly, but called by driver .probe() which is triggered inside module_init().

I admit that it is weird if the driver is built in kernel. But considered that
most of drivers are built as module, it should be workable since the
userspace is already ready during module probing.

Also from the viewpoint of device driver, loading driver inside .probe()
is reasonable since the device may be powered on just now and
can't work further without the firmware.

Finally, the reality is that hundreds of drivers call request_firmware()
inside their.probe(), and converting them into its asynchronous pair
will introduce much much works, :-(

>
> The firmware loading call should not rely on a fully functional
> userspace, and modprobe should not hang and block until the firmware
> request is handled.

IMO, the driver probing path is allowed to sleep, so looks request firmware
should be allowed inside .probe().

In the patch I posted, it will make the situation workable at least.

>From udevd code, the firmware ADD event isn't run until its parent
device has been handled. IMO,  looks like there is no obvious side
effect to loose the constraint for firmware device.

Correct me if it is wrong, and I am not familiar with udev.

>
> The firmware should be requested asynchronously or from a different
> context as module_init(). It depends on the type of driver/hardware
> what's the best approach here.

Requesting firmware asynchronously should be better, but may
introduce some complexity to drivers, for example, race between
request/release firmware context and hotplug contexts.


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/