[PATCH 0/3] firmware_class: Fix problem with async requests (was: Re: [RFC] firmware loader: retry ...)

[Rafael J. Wysocki]

On Sunday, March 18, 2012, Christian Lamparter wrote:
> On Sunday 18 March 2012 01:29:38 Rafael J. Wysocki wrote:
> > The patch below (untested) goes slightly into that direction, although not as
> > far as to modify fw_create_instance().  It does, however, split
> > _request_firmware() into "prepare", "load" and "cleanup" parts and moves
> > the usermodehelper check along with the read-locking of umhelper_sem down
> > to the callers, ie. request_firmware() and request_firmware_work_func().
> > 
> > The difference between them is that request_firmware() fails immediately
> > with a WARN_ON() if it sees usermodehelper_disabled set after acquiring
> > umhelper_sem, while request_firmware_work_func() waits for
> > usermodehelper_disabled to be unset, with a timeout (the wait time is
> > subtracted from the _request_firmware() timeout).  The reason why
> > request_firmware_work_func() does it this way is that it can't wait for
> > usermodehelper_disabled to be unset with umhelper_sem held and it has to
> > call _request_firmware() under umhelper_sem (otherwise user space might be
> > frozen out from under it).
> > 
> > I'm falling asleep now, but hopefully the patch isn't totally busted. :-)
> > It should be split into a series of patches, though.
> I'm happy to report that my test system [with the patch applied] suspended
> and resumed without any incidents.

Thanks for testing!

The following three patches should result in analogous code, although slightly
cleaned up.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/