Re: Re: Suspend without the freezer

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Wednesday, 1 August 2007 16:33, Alan Stern wrote:
> On Wed, 1 Aug 2007, Paul Mackerras wrote:
> 
> > Alan Stern writes:
> > 
> > > I think this is subject to the same weakness Dmitry mentions: By the
> > > time the driver would block on the new rwsem, it has already started
> > > mucking with the device.  Worse yet, it may hold a mutex that the 
> > > suspend method needs, thereby deadlocking the suspend.  (That's what 
> > > would happen with serio->drv_mutex in the input layer.)
> > > 
> > > Maybe the best answer is simply to fail all attempts at device
> > > registration while a suspend is underway.  At least that is a known
> > > error path which drivers are prepared (in theory) to deal with.  It
> > > could be implemented quite easily with an rwsem, by making the
> > > registration code use down_read_trylock.
> > 
> > What about making a list of devices that drivers have attempted to
> > register?  While the system is suspending, if a driver attempts to
> > register a device, put it on a list and return success.  Then, after
> > resuming, run through the list and actually process them.
> 
> I'm not sure it's safe to lie to drivers, telling them that their 
> device has been registered when in fact it hasn't.  For instance, what 
> if the driver then calls device_create_file()?  Safe or not, it 
> certainly isn't transparent and therefore isn't a good thing to do.

I agree.

I'm always cautious about things like that, because they almost certainly
break someone's assumptions. 
 
> Of course, the problem with my approach is that it puts the burden on
> drivers of blocking threads which want to register devices.  This turns
> out to be distressingly difficult -- easier just to let them fail.  I
> was hoping to find a centralized solution but apparently there isn't
> one.
> 
> A better approach would be to fail registrations only if the parent is
> already suspended.  Maybe that can be made to work... but I'm doubtful.  
> (What if the parent gets suspended _during_ the child's registration?)
> 
> > I guess removal during suspend/resume should remove the list entry, if
> > the device is one of the ones on the list.  Otherwise, is there a
> > problem with letting removals proceed during suspend/resume?  (In
> > general removal can be notified after the device has physically
> > disappeared IIRC, so driver unbind functions have to avoid touching
> > the device or at least be prepared to deal with it not responding.)
> 
> I don't think removal during suspend poses a serious problem.  It can
> never lead to a situation where a suspended parent has an unsuspended
> child, which is what we need to avoid.

With our current design, removal during resume, before the device is put back
onto dpm_active, may lead to nasty problems.  I haven't analysed that in
detail, but at least generally it seems highly suspicious to me.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth