linux-kernel - Re: [PATCH 1/2] PM / sleep: ensure deferred probe workqueue is finished in wait_for_device

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]

Date:	Thu, 8 Oct 2015 16:53:12 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
cc:	Grygorii Strashko <grygorii.strashko@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
	<linux-kernel@...r.kernel.org>, <linux-pm@...r.kernel.org>,
	Thierry Reding <thierry.reding@...il.com>
Subject: Re: [PATCH 1/2] PM / sleep: ensure deferred probe workqueue is
 finished in wait_for_device_probe

On Thu, 8 Oct 2015, Rafael J. Wysocki wrote:

> > @@ -391,6 +391,10 @@ int driver_probe_done(void)
> >   */
> >  void wait_for_device_probe(void)
> >  {
> > +	/* wait for the deferred probe workqueue to finish */
> > +	if (driver_deferred_probe_enable)
> > +		flush_workqueue(deferred_wq);
> > +
> >  	/* wait for the known devices to complete their probing */
> >  	wait_event(probe_waitqueue, atomic_read(&probe_count) == 0);
> >  	async_synchronize_full();
> 
> I'm not sure if this is sufficient.
> 
> Something may be added to the workqueue right after you've flushed it and
> then be reporobed after the wait_event() in theory.  Or am I missing anything?

Maybe I'm missing part of this, but I think the point is to make sure 
that every probe which began or was queued before this function got 
called, has finished before the function returns.

Thus, in the case at hand we want to defer all probes starting from
some point in the system sleep transition.  Grygorii sets his
defer_all_probes variable and then calls this function.  It waits for
any probes that were initiated before the function call.  Any probe
that was initiated after the function call (for example, the ones
you're concerned about between the flush_workqueue and wait_event) will
see that defer_all_probes is set and so will defer itself.

Now, I'm not sure what happens when a probe that was deferred tries to 
defer itself again.  Do we end up in an infinite probing loop?  Is
the deferred_wq workqueue freezable?

Alan Stern

--
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/