netdev - Re: calling request_firmware() from module init will not work with recent/future udev versions

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, 16 Feb 2012 14:09:38 +0100
From:	"Arend van Spriel" <arend@...adcom.com>
To:	"Johannes Berg" <johannes@...solutions.net>
cc:	"Kay Sievers" <kay.sievers@...y.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"Tom Gundersen" <teg@...m.no>, "Andy Whitcroft" <apw@...onical.com>
Subject: Re: calling request_firmware() from module init will not work
 with recent/future udev versions

On 02/16/2012 01:38 PM, Johannes Berg wrote:
> On Thu, 2012-02-16 at 13:04 +0100, Arend van Spriel wrote:
>> On 01/16/2012 09:57 AM, Johannes Berg wrote:
>>>> Now the problem, the pcidev event is blocking in modprobe and waits
>>>>>   for the child event it has generated to finish, but udev does not
>>>>>   start the event because the parent still blocks in modprobe ->
>>>>>   deadlock until default firmware timeout of 60 sec. What we want here,
>>>>>   for several reasons not only udev's dependency logic, is that modprobe
>>>>>   never waits for userspace transactions to finish.
>>> Ok, thanks for the description. I guess to me that means nothing really
>>> changes much in the situation I'm thinking of.
>>
>> I am working on changes in brcm80211 driver and the behaviour changes
>> slightly. The async firmware request basically kicks of a kernel thread
>> to do the actual request. So the probe finishes successfully regardless
>> what the results will be of the actual firmware request. Hence the
>> driver is associated with the hardware.
>
> This is true.
>
>>>>>   If userspace is not responding, the firmware request times out after
>>>>>   60 seconds and the driver is not associated with any hardware. To
>>>>>   retry the firmware loading, the module needs to be unloaded and
>>>>>   reloaded, or the driver needs to be asked to bind to a device again by
>>>>>   writing to the 'bind' in file in the sysfs driver directory.
>>> Right.
>>>
>>
>> If my previous statement is true, what does it mean regarding retrying
>> the firmware loading?
>
> When the firmware loading fails, the driver should unbind from the
> device that it failed for, and the retrying behaviour doesn't change
> (and requires a rebind)
>
> johannes
>
>

Thanks, Johannes

That helps. My driver was happily bound to the device until unloading 
the driver or unplugging the device.

Gr. AvS

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html