[lkml]   [2012]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH 0/3] firmware_class: Fix problem with async requests (was: Re: [RFC] firmware loader: retry ...)
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.


 \ /
  Last update: 2012-03-19 00:19    [W:0.168 / U:5.656 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site