On Fri, 2009-01-23 at 23:12 -0500, Bob Copeland wrote:
> [apologies for resend, forgot to cc wireless]
>
> Commit 59959a6150c8af737898e83f727e824dbed7b0fa made the mac80211
> workqueue freezeable to prevent us from doing any work after the
> driver went away. This was fine before mac80211 had any suspend
> support.
>
> However, now we want to flush this workqueue in suspend(). Because
> the thread for a freezeable workqueue is stopped before the device
> class suspend() is called, flush_workqueue() will hang in the
> suspend-to-disk case.
>
> Converting it back to a non-freezeable queue will keep suspend from
> hanging. Moreover, since we flush the workqueue under RTNL and
> userspace is stopped, there won't be any new work in the workqueue
> until after resume. Thus we still don't have to worry about pinging
> the AP without hardware.
Good catch! Do we have to freeze the workqueue ourselves manually or
something, to avoid drivers adding work to it?
> Signed-off-by: Bob Copeland <me@xxxxxxxxxxxxxxx>
> ---
> net/mac80211/main.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index a100793..a109c06 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -859,7 +859,7 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
> mdev->set_multicast_list = ieee80211_master_set_multicast_list;
>
> local->hw.workqueue =
> - create_freezeable_workqueue(wiphy_name(local->hw.wiphy));
> + create_singlethread_workqueue(wiphy_name(local->hw.wiphy));
> if (!local->hw.workqueue) {
> result = -ENOMEM;
> goto fail_workqueue;
> --
> 1.6.0.6
>
Attachment:
signature.asc
Description: This is a digitally signed message part
