netdev - rtnl_mutex deadlock?

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-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFwYhdHdLUbYYAc9GgmFuVXniwAESYHuzDWjdapPC0m1Xw@mail.gmail.com>
Date:	Tue, 4 Aug 2015 08:48:23 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	Thomas Graf <tgraf@...g.ch>, Jiri Pirko <jiri@...nulli.us>,
	Scott Feldman <sfeldma@...il.com>,
	Daniel Borkmann <daniel@...earbox.net>
Cc:	Network Development <netdev@...r.kernel.org>
Subject: rtnl_mutex deadlock?

Sorry for the spamming of random rtnetlink people, but I just resumed
my laptop at PDX, and networking was dead.

It looks like a deadlock on rtnl_mutex, possibly due to some error
path not releasing the lock. No network op was making any progress,
and as you can see from the attached sysrq-w, it all seems to be hung
in rtnl_lock().

The call trace from NetworkManager looks different from the others,
and looks to me like it might actually be a recursive invocation of
rtnetlink_rcv(), but since I have a fairly light configuration on this
laptop and don't have frame pointers enabled, I'm not sure how
reliable that stack trace is. It might be just stale entries. But if
they aren't stale, then that would certainly explain the deadlock.

I had to reboot the laptop to get it to be usable, and the problem
didn't happen again, so I have no other real debugging info to help.

The only thing special here was that I suspended the machine in one
wireless network, and resumed it in another one. That doesn't sound
very special to me, but it's the only thing remotely different from my
normal suspend/resume cycles that have worked fine during this release
so far..

                     Linus

Download attachment "hung-wireless-after-resume" of type "application/octet-stream" (26458 bytes)