lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 19 Dec 2007 10:58:02 +0800
From:	Zhu Yi <>
To:	Johannes Berg <>
Cc:	Miles Lane <>, Len Brown <>,
	netdev <>,
	LKML <>,,
	"Rafael J. Wysocki" <>, Pavel Machek <>,
	Andrew Morton <>
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.


View attachment "fix-3945-deadlock-susp.patch" of type "text/x-patch" (2207 bytes)

Powered by blists - more mailing lists