Re: [PATCH] mac80211: Fix deadlock in ieee80211_do_stop.

From: Johannes Berg <johannes@sipsolutions.net>
To: greearb@candelatech.com
Cc: linux-wireless@vger.kernel.org, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH] mac80211:  Fix deadlock in ieee80211_do_stop.
Date: Fri, 12 Nov 2010 12:49:58 -0800	[thread overview]
Message-ID: <1289594998.3736.11.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1289592426-5367-1-git-send-email-greearb@candelatech.com>

On Fri, 2010-11-12 at 12:07 -0800, greearb@candelatech.com wrote:

> -		flush_work(&sdata->work);
> +		/* Cannot call flush_work here because we are holding
> +		 * RTNL and the worker thread(s) that will be called upon to
> +		 * do the flushing might already be running a piece of work
> +		 * that is blocking on RTNL.  That leads to deadlock and/or
> +		 * OOM.
> +		 */
> +		cancel_work_sync(&sdata->work);

I don't think that comment really belongs into the sources at all ... if
we did that all the time we'd have no sources left between the
comments :-)

However, I also don't think it should be necessary to do this.
sdata->work is always queued on local->workqueue, which is created using
alloc_ordered_workqueue(), and there is no work on this workqueue that
uses the RTNL. Therefore, even flushing the entire workqueue must work,
unless alloc_ordered_workqueue() has no such guarantee any more -- which
I would consider to be a bug in the new workqueue framework.

johannes