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]

Date:   Wed, 1 Sep 2021 16:48:44 -0500
From:   Larry Finger <Larry.Finger@...inger.net>
To:     Johannes Berg <johannes@...solutions.net>,
        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 9/1/21 14:49, Johannes Berg wrote:
> 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
> 
I am seeing the same problem, and it does happen in lots of places. For example

finger@...3-8090-2005-39b3-0000-0000-0000-1023:~/rtl8812au>dmesg | grep 
assertion\ failed
[    6.465589] RTNL: assertion failed at net/core/rtnetlink.c (1702)
[    6.465948] RTNL: assertion failed at net/core/devlink.c (11496)
[    6.466263] RTNL: assertion failed at net/core/rtnetlink.c (1412)
[    6.466500] RTNL: assertion failed at net/core/dev.c (1987)
[    6.466708] RTNL: assertion failed at net/core/fib_rules.c (1227)
[    6.466902] RTNL: assertion failed at net/ipv4/devinet.c (1526)
[    6.467097] RTNL: assertion failed at net/ipv4/igmp.c (1779)
[    6.467291] RTNL: assertion failed at net/ipv4/igmp.c (1432)

I am in the process of bisecting the problem, just in case it happens some other 
place than your suspicion leads you.

Larry