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]

Message-ID: <1329395881.3915.7.camel@jlt3.sipsolutions.net>
Date:	Thu, 16 Feb 2012 13:38:01 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Arend van Spriel <arend@...adcom.com>
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 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

--
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