On 01/14/2012 04:25 PM, Kay Sievers wrote:

We changed udev to strictly enforce sequence order and dependency
handling of events. This seems to break some netdev drivers which
block in modprobe until the firmware from userspace is loaded into the
driver.

Working on the issue complicated the behavior of the driver so I decided 
to take a step back to determine the actual issue.

These are the drivers we received bug reports so far. We didn't look
into any of details of the drivers, but according to the logs, they
seem to block for 60 seconds in modprobe, when userspace is not
behaving like expected:
   bnx2/bnx2-mips-06-6.2.1.fw
   rtlwifi/rtl8192sefw.bin
   brcm/bcm43xx-0.fw

The main problem is that the init_module() syscall should not block. 
However, the driver I am responsible for (brcm80211) does not request 
firmware in the init_module() path. It does that on the probe() 
callback. So the problem is that the probe() code path is done in the 
context of the init_module() syscall. So the thing to do is decouple the 
probe() callback from the init_module() syscall.

One option is using the nowait version of request_firmware(), but 
another option I am considering is to defer the driver registration 
using a workqueue and schedule it in the init_module() syscall. That way 
I think I can avoid having to call the device_unregister_driver() when 
firmware loading fails.

Another thing to consider is to change the driver core subsystem and 
assure the probe() callback is never done in the init_module() context.

Any opinions?

Gr. AvS