netdev - Re: MT7922 problem with "fix rx filter incorrect by drv/fw inconsistent"

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

Date: Mon, 26 Jun 2023 15:31:57 +0200
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@...mhuis.info>
To: Kalle Valo <kvalo@...nel.org>
Cc: Andrey Rakhmatullin <wrar@...r.name>,
 Linux regressions mailing list <regressions@...ts.linux.dev>,
 linux-wireless@...r.kernel.org, Neil Chen <yn.chen@...iatek.com>,
 Deren Wu <deren.wu@...iatek.com>, Lorenzo Bianconi <lorenzo@...nel.org>,
 Felix Fietkau <nbd@....name>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 netdev <netdev@...r.kernel.org>
Subject: Re: MT7922 problem with "fix rx filter incorrect by drv/fw
 inconsistent"

Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.

FWIW, I'm dropping this from the list of tracked regressions now. This
wasn't handled as it IMHO should be, but whatever, at this point it
afaics is best to leave things as they are, unless more reports of this
kind show up.

Thx everyone.

#regzbot inconclusive: not fixed, but fixing likely would cause more
trouble than it's worth, unless more people complain

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

On 19.06.23 14:48, Thorsten Leemhuis wrote:
> On 12.06.23 14:39, Kalle Valo wrote:
>> Thorsten Leemhuis <regressions@...mhuis.info> writes:
>>> On 22.05.23 16:12, Thorsten Leemhuis wrote:
>>>> On 22.05.23 15:20, Andrey Rakhmatullin wrote:
>>>>> On Mon, May 22, 2023 at 03:00:30PM +0200, Linux regression tracking
>>>>> #adding (Thorsten Leemhuis) wrote:
>>>>>> On 18.05.23 16:39, Andrey Rakhmatullin wrote:
>>>>> I updated the firmware and now the problem doesn't happen.
>>>>> The firmware where the problem happens is
>>>>> mediatek/WIFI_RAM_CODE_MT7922_1.bin from the linux-firmware commit
>>>>> e2d11744ef (file size 826740, md5sum 8ff1bdc0f54f255bb2a1d6825781506b),
>>>>> the one where the problem doesn't happen is from the commit 6569484e6b
>>>>> (file size 827124, md5sum 14c08c8298b639ee52409b5e9711a083).
>>>> FWIW, just checked: that commit is from 2023-05-15, so quite recent.
>>>>
>>>>> I haven't
>>>>> tried the version committed between these ones.
>>>>> Not sure if this should be reported to regzbot and if there are any
>>>>> further actions needed by the kernel maintainers.
>>>>
>>>> Well, to quote the first sentence from
>>>> Documentation/driver-api/firmware/firmware-usage-guidelines.rst
>>>>
>>>> ```Users switching to a newer kernel should *not* have to install newer
>>>> firmware files to keep their hardware working.```
>>>>
>>>> IOW: the problem you ran into should not happen. This afaics makes it a
>>>> regression that needs to be addressed -- at least if it's something that
>>>> is likely to hit others users as well. But I'd guess that's the case.
>>>
>>> Well, until now I didn't see any other report about a problem like this.
>>> Maybe things work better for others with that hardware – in that case it
>>> might be something not worth making a fuzz about. But I'll wait another
>>> week or two before I remove this from the tracking.
>>
>> Yeah, this is bad. mt76 (or any other wireless driver) must not require
>> a new firmware whenever upgrading the kernel. Instead the old and new
>> firmware should coexist (for example have firmware-2.bin for the new
>> version and firmware.bin for the old version). Then mt76 should first
>> try loading the new firmware (eg. firmware-2.bin) and then try the old
>> one (eg. firmware.bin).
>>
>> Should we revert commit c222f77fd4 or how to solve this?

> Hmmm. Tricky. This was the only such report I noticed. Giving that and
> the risk that a revert might cause regressions on its own, I guess it
> might be better to leave everything as it is for now - and re-evaluate
> the situation in case more problems show up.