linux-kernel - Re: [RFC][PATCH] PM: Make PM core handle device registrations concurrent with suspend/hibernation

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: <200803062118.32860.rjw@sisk.pl>
Date:	Thu, 6 Mar 2008 21:18:32 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	pm list <linux-pm@...ts.linux-foundation.org>,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	Pavel Machek <pavel@....cz>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] PM: Make PM core handle device registrations concurrent with suspend/hibernation

On Thursday, 6 of March 2008, Alan Stern wrote:
> On Thu, 6 Mar 2008, Rafael J. Wysocki wrote:
> 
> > > I thought of one more thing you might want to add: device_pm_add() 
> > > doesn't handle the case where dev->parent is NULL.
> > 
> > I'm not sure what you mean.
> > 
> > If dev->parent is NULL, we get into the "successful" branch where the device is
> > added to dpm_active.  Do you think we should add any extra handling of this
> > case?
> 
> If a device is registered after dpm_suspend() has returned, the
> device won't be suspended properly before the system goes to sleep.  
> 
> If the device has a parent then you're okay, because the parent must
> already be suspended and so device_pm_add() will fail.  But if the
> device doesn't have a parent then device_pm_add() will succeed, which
> you don't want.

Well, can it happen in practice?  If it can, then what way can it happen?

> > > You could put in that static "all_devices_sleeping" flag, which gets set at
> > > the end of dpm_suspend() and cleared at the start of dpm_resume().
> > 
> > Well, I don't think it's necessary.  dpm_active is empty in that case and
> > we can use the list_empty(&dpm_active) check instead.
> 
> What would happen the very first time the system registers a device 
> during startup?

For any other uses than in device_pm_add(), the list_empty(&dpm_active) test
should be sufficient, IMHO.

It seems to me that we're discussing purely academic stuff here.  If it turns
out to be of any practical relevance, it will be trivial to add the handling of
it in the future.

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