[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1198033082.2857.303.camel@debian.sh.intel.com>
Date: Wed, 19 Dec 2007 10:58:02 +0800
From: Zhu Yi <yi.zhu@...el.com>
To: Johannes Berg <johannes@...solutions.net>
Cc: Miles Lane <miles.lane@...il.com>, Len Brown <len.brown@...el.com>,
netdev <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
ipw3945-devel@...ts.sourceforge.net,
"Rafael J. Wysocki" <rjw@...k.pl>, Pavel Machek <pavel@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [ipw3945-devel] 2.6.24-rc5-mm1 -- INFO: possible circular
locking dependency detected -- pm-suspend/5800 is trying to acquire lock
On Tue, 2007-12-18 at 15:57 +0100, Johannes Berg wrote:
> Thanks. This is a bug in iwlwifi.
>
> The problem is actually another case where my workqueue debugging with
> lockdep is triggering a warning :))
>
> Here's the thing:
>
> iwl3945_cancel_deferred_work does
>
> cancel_delayed_work_sync(&priv->init_alive_start);
>
> (which is the "(&(&priv->init_alive_start)->work)" lock)
>
> but it is called from within a locked section of
> mutex_lock(&priv->mutex); (locked from iwl3945_pci_suspend)
>
> On the other hand, the task that runs from the init_alive_start
> workqueue is iwl3945_bg_init_alive_start() which will lock the same
> mutex.
>
> So the deadlock condition is that you can be in
> cancel_delayed_work_sync() above while the mutex is locked, and be
> waiting for iwl_3945_bg_init_alive_start() which tries to lock the
> mutex.
Thanks for the analysis.
Miles, please try the attached patch. I'll send a patch for both 3945
and 4965 to linux-wireless later.
Thanks,
-yi
View attachment "fix-3945-deadlock-susp.patch" of type "text/x-patch" (2207 bytes)
Powered by blists - more mailing lists