Re: [PATCH w-t] iwlwifi: rewrite iwl-scan.c to avoid race conditions

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2010-09-01 at 16:16 +0200, Stanislaw Gruszka wrote:
> On Wed, Sep 01, 2010 at 02:41:52PM +0200, Johannes Berg wrote:
> > > Custom workqueue is not strictly needed, but it assure all works will
> > > run short after schedule. Common workqueue can not give us such guarantees,
> > > as other driver/subsystem can schedule own work, possibly slow, which
> > > can block start of our work for long time.
> > 
> > I believe that's no longer true, with Tejun's workqueue rewrite that
> > just got into mainline.
> 
> Good. However I still think having separate workqueue for scanning is clean
> and consistent solution, I prefer it over schedule_work() ... and want
> that patch backport to RHEL6 2.6.32 where we do not have such goodies :-)

Ah, but Tejun will kill us if we add more workqueues to the current
kernel :-)

> > > For sure abort_scan and abort_timeout works have to be scheduled on something
> > > other than priv->workqueue. I'm queuing all scan works on priv->scan_workqueue
> > > for consistency.
> > 
> > Remind me: The reason is that we need to cancel them from within the
> > workqueue? But if we're on the same workqueue, it seems like they
> > couldn't be running already, so cancel_work_sync() would always cancel
> > them? 
> 
> Problem is not canceling, but exactly that we can not run new work when
> old one does not finish. For example, if queued to priv->workqueue
> abort_timeout will not be able run when we are performing iwl_bg_restart.
> Will run after iwl_bg_restart finish, we don't want that.

Ok ... Not sure I understand. Why do we care about abort_timeout work
coming after it? We'd cancel it anyway, when we kill the scan from
bg_restart, no?

johannes