linux-kernel - Re: [BISECTED] 5.12 hangs at reboot

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:   Mon, 26 Apr 2021 21:19:49 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Harald Arnesen <harald@...gtun.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Kalle Valo <kvalo@...eaurora.org>,
        linux-wireless@...r.kernel.org
Subject: Re: [BISECTED] 5.12 hangs at reboot

On Mon, 2021-04-26 at 18:59 +0000, Linus Torvalds wrote:
> On Mon, Apr 26, 2021 at 11:47 AM Harald Arnesen <harald@...gtun.org> wrote:
> > 
> > Bisected to commit 776a39b8196dbca4afb69669db0d9926ffac29ab, and
> > reverting this makes the machine reboot as usual.
> 
> Hmm. That was already in rc1, so this isn't some late untested
> last-minute commit that broke things for you.

At least _that_ isn't, could be some other change elsewhere triggered
it? OTOH, then bisect should've landed there, and not on this, since
this came in early and merges with other stuff would've happened later.
So ...

> Which implies that it's likely something fairly specific to  your
> setup (either the config or the hardware - or possibly Void Linux
> doing something other distros don't).

Probably hardware (well, driver), cfg80211_destroy_ifaces() calls into
the driver.

Which wireless driver are you using? Looking at all of the ones in 5.12,
I see that
 * ath6kl obviously deadlocks immediately regardless of this change
   (Kalle, ISTR pointing this out to you a long time ago while I was
   developing the locking changes here?).
 * wil6210 is broken if you use P2P, and I can only blame myself for
   that, will send a fix; maybe that's the difference in your distro?
   But I think P2P on 60 GHz is not used much.
 * brcmfmac looks a bit fishy, but that seems unrelated to my code, I'll
   send an RFC patch to see what's that really doing
 * staging/rtl8723bs also looks bad, and needs to use
   cfg80211_unregister_netdevice() instead of just
   unregister_netdevice(), I'll also send a patch.

The others look fine. Not sure why I didn't see this before, I went over
it with a fine comb back then ... sorry.

Are you using one of the above?

The other special thing might be that you're actually explicitly
deleting (virtual) wireless interfaces, which isn't *that* common,
though of course not really uncommon either.

> Mind also attaching a dmesg of an affected kernel (or with the revert
> in place, I guess - it shouldn't matter until the reboot ;)
> 
> There's a lockdep assertion there, but you don't seem to have lockdep
> enabled. So it be interesting to see what happens if you
> 
>  (a) enable lockdep
> 
>  (b) make sure to reboot in text mode so that any lockdep messages
> would actually be visible.
> 
> Maybe Johannes will go "Doh!" and see what's wrong.

Almost certainly will :)

And here I was so happy that this survived from rc1 until the release
with just a handful of issues ;-)

Thanks!

johannes