From: Johannes Berg <johannes@sipsolutions.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Harald Arnesen <harald@skogtun.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [BISECTED] 5.12 hangs at reboot
Date: Mon, 26 Apr 2021 22:11:45 +0200 [thread overview]
Message-ID: <bca302812cece1972bed7efe34a9d554b9e912ed.camel@sipsolutions.net> (raw)
In-Reply-To: <CAHk-=wiwByiEUuO-NN=xHb4sxwCmP=tjB_vUHEebj8+-JGu8zg@mail.gmail.com> (sfid-20210426_215145_178898_2C6EEF9D)
On Mon, 2021-04-26 at 12:51 -0700, Linus Torvalds wrote:
> On Mon, Apr 26, 2021 at 12:46 PM Johannes Berg
> <johannes@sipsolutions.net> wrote:
> >
> > Right. Maybe if it's modules, could try to remove them rather than
> > reboot?
>
> Yes, doing an 'rmmod ath9k' (or whatever that module is called)
> sounds like a good idea, it might trigger the same lockup.
>
> In fact, that might be the reason Harald sees this - maybe Void Linux
> tries to unload modules before rebooting, and other distros don't?
Seems odd if they would, but maybe?
I guess we're well into speculation here now - Harald, even taking a
picture of a stack dump will help, I'll likely only need an indication
where it's actually locking up, unless it's actually in
cfg80211_destroy_iface_wk() itself, but I can't see how that'd be
possible.
Looks like with mac80211 this really should just go down into
ieee80211_if_remove() and that looks OK.
And it's coming from a work struct, so I thought maybe some flushing
happened in a bad context, but that's only in wiphy_unregister(),
without the lock(s) held around it, as it should be. I figured then
maybe wiphy_unregister() could be called in a bad context, but then that
would've deadlocked itself earlier, unrelated to the destroy_iface_wk().
Oh, I have another idea - maybe void linux is using iwd instead of
wpa_supplicant, and that insists on doing the netlink owner stuff so
everything is deleted in case it crashes. But I've been looking at the
code pretty much assuming that we get actual calls down, so ...
Dunno. I don't see anything obvious right now, any additional
information (stack dump, or lockdep report) would be great.
johannes
next prev parent reply other threads:[~2021-04-26 20:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-26 18:43 Harald Arnesen
2021-04-26 18:59 ` Linus Torvalds
2021-04-26 19:19 ` Johannes Berg
2021-04-26 20:23 ` Harald Arnesen
2021-04-26 19:29 ` Harald Arnesen
2021-04-26 19:38 ` Johannes Berg
2021-04-26 19:45 ` Linus Torvalds
2021-04-26 19:46 ` Johannes Berg
2021-04-26 19:51 ` Linus Torvalds
2021-04-26 20:11 ` Johannes Berg [this message]
2021-04-26 20:25 ` Harald Arnesen
[not found] ` <151b7e41-a415-e780-eb90-6ca16c113066@skogtun.org>
2021-04-26 22:49 ` Linus Torvalds
2021-04-27 7:43 ` Herbert Xu
2021-04-27 8:49 ` Johannes Berg
2021-04-26 20:10 ` Harald Arnesen
2021-04-26 20:26 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bca302812cece1972bed7efe34a9d554b9e912ed.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=harald@skogtun.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®