netdev - Re: [0/5] bcma/brcmsmac suspend/resume cleanups and fixes

lists.openwall.net		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:	Sat, 14 Jan 2012 15:28:20 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dominique Martinet <asmadeus@...ewreck.org>
Cc:	Arend van Spriel <arend@...adcom.com>,
	Rafał Miłecki <zajec5@...il.com>,
	Larry Finger <Larry.Finger@...inger.net>,
	Alwin Beukers <alwin@...adcom.com>,
	Roland Vossen <rvossen@...adcom.com>,
	"John W. Linville" <linville@...driver.com>,
	Network Development <netdev@...r.kernel.org>,
	"Franky (Zhenhui) Lin" <frankyl@...adcom.com>
Subject: Re: [0/5] bcma/brcmsmac suspend/resume cleanups and fixes

On Sat, Jan 14, 2012 at 3:08 PM, Dominique Martinet
<asmadeus@...ewreck.org> wrote:
>
> Right, I missed it. Suspend works as long as I don't use wireless
> before.

Ok. Your suspend hang may be related to the cfg80211_wext hang that is
apparently unrelated to the issues we saw.

> I still get a warning:
>
> [   30.256946] ------------[ cut here ]------------
> [   30.256956] WARNING: at drivers/base/core.c:194 device_release+0x6a/0x73()

Yes. This warning is annoying but harmless. We'll fix it some way
(possibly by just turning it back to a single line, like it used to
be), but for now you can just ignore it.

> brcmsmac seems to have a problem that looks like it's fixed in
> wireless-next, after a suspend if it's been used then all network
> operation hang (i.e. 'ip addr', something like resolving an host doesn't
> work but doesn't hang either, modprobe -r brcmsmac hangs as well)
> Here's the revelent information about this:
>
> [  361.248353] INFO: task wpa_supplicant:9102 blocked for more than 120 seconds.
> [  361.248362] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [  361.248367] wpa_supplicant  D ffff880062d68400     0  9102      1 0x00000000
> [  361.248397] Call Trace:
> [  361.248411]  [<ffffffff81313307>] ? __mutex_lock_common.clone.5+0x114/0x179
> [  361.248432]  [<ffffffffa03bef8a>] ? cfg80211_wext_siwscan+0xbd/0x2dc [cfg80211]
> [  361.248439]  [<ffffffff81313137>] ? mutex_lock+0x12/0x25
> [  361.248458]  [<ffffffffa03f83c1>] ? ieee80211_request_scan+0x20/0x4e [mac80211]

Ok, judging by the call trace this seems to be a generic wireless bug,
likely not a brcmsmac bug.  Presumably people like me (and obviously
wireless developers) avoid this by not using wpa_supplicant o
rsomething. You might want to enable LOCKDEP to verify - if it's a
deadlock (either direct, or ABBA) - lockdep should give you a big
splat immediately rather than having to wait for 2 minutes.

Linwille/David - can you please make sure the fix gets to my tree,
since it's apparently already ok in the development tree?

                     Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html