On Thursday, October 08, 2015 11:57:06 AM Grygorii Strashko wrote: > Now wait_for_device_probe() waits for currently executing probes to finish, > but it doesn't take into account deferred probing mechanism. As result, > nothing prevents deferred probe workqueue to continue probing devices right > after wait_for_device_probe() is finished. > > Hence, lest ensure deferred probe workqueue is finished in
s/lest/let's/ > wait_for_device_probe() before proceeding. > > Cc: Alan Stern <[email protected]> > Cc: Rafael J. Wysocki <[email protected]> > Cc: Thierry Reding <[email protected]> > Signed-off-by: Grygorii Strashko <[email protected]> > --- > drivers/base/dd.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c > index be0eb46..98de1a5 100644 > --- a/drivers/base/dd.c > +++ b/drivers/base/dd.c > @@ -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? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
