linux-kernel - Re: [GIT PULL] Networking for v5.15

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]

Message-ID: <4dfae09cd2ea3f5fe4b8fa5097d1e0cc8a34e848.camel@sipsolutions.net>
Date:   Wed, 01 Sep 2021 21:49:32 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Jakub Kicinski <kuba@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Luca Coelho <luciano.coelho@...el.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-wireless@...r.kernel.org,
        Miri Korenblit <miriam.rachel.korenblit@...el.com>
Subject: Re: [GIT PULL] Networking for v5.15

On Wed, 2021-09-01 at 12:41 -0700, Jakub Kicinski wrote:
> 
> > 
> > They all seem to have that same issue, and it looks like the fix would
> > be to get the RTN lock in iwl_mvm_init_mcc(), but I didn't really look
> > into it very much.
> > 
> > This is on my desktop, and I actually don't _use_ the wireless on this
> > machine. I assume it still works despite the warnings, but they should
> > get fixed.
> > 
> > I *don't* see these warnings on my laptop where I actually use
> > wireless, but that one uses ath10k_pci, so it seems this is purely a
> > iwlwifi issue.
> > 
> > I can't be the only one that sees this. Hmm?
> 
> Mm. Looking thru the recent commits there is a suspicious rtnl_unlock()
> in commit eb09ae93dabf ("iwlwifi: mvm: load regdomain at INIT stage").

Huh! That's not the version of the commit I remember - it had an
rtnl_lock() in there too (just before the mutex_lock)?! Looks like that
should really be there, not sure how/where it got lost along the way.

That unbalanced rtnl_unlock() makes no sense anyway. Wonder why it
doesn't cause more assertions/problems at that point, clearly it's
unbalanced. Pretty sure it's missing the rtnl_lock() earlier in the
function for some reason.

Luca and I will look at it tomorrow, getting late here, sorry. 

johannes