linux-kernel - Re: [regression] ath11k broken in v6.7

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: <0253854a-e5f9-4316-bec3-61aaf3ebfd1a@leemhuis.info>
Date: Mon, 22 Jan 2024 11:24:06 +0100
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: Kalle Valo <kvalo@...nel.org>
Cc: ath11k@...ts.infradead.org,
 Linux regressions mailing list <regressions@...ts.linux.dev>,
 linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [regression] ath11k broken in v6.7

On 22.01.24 09:24, Kalle Valo wrote:
> "Linux regression tracking (Thorsten Leemhuis)"
> <regressions@...mhuis.info> writes:
>> On 22.01.24 08:36, Kalle Valo wrote:
>>> Kalle Valo <kvalo@...nel.org> writes:
>>>> Kalle Valo <kvalo@...nel.org> writes:
>>>>> Kalle Valo <kvalo@...nel.org> writes:
>>>>>>
>>>>>> Proposed fix:
>>>>>> https://patchwork.kernel.org/project/linux-wireless/patch/20240111170629.1257217-1-benjamin@sipsolutions.net/
>>>>> The fix is now applied:
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=556857aa1d0855aba02b1c63bc52b91ec63fc2cc
>>>>> I'll try to use regzbot for the first time, let's see how it goes:
>>>>> #regzbot introduced: 0a3d898ee9a8 ^
>>>> Forgot to include the bug report:
>>>>
>>>> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218364
>>
>> FWIW, that usage was slightly off and not how it's supposed to be done.
>> But whatever, let's ignore that. I'm reworking things currently
>> slightly, as you are not the first one that slightly got mislead -- and
>> the newer commands will hopefully be mire intuitive.
> 
> Just to educate myself, how should I have done it? (But feel free to
> skip the question if you are busy)

I think that's not worth it, as I hope to introduce the new commands in
the near future (but you know how it is with the last 5 to 10
percent...). But let me show you how it's then supposed to be done in
this situation, that way you can give early feedback:

  #regzbot report: https://bugzilla.kernel.org/show_bug.cgi?id=218364
  #regzbot introduced: 0a3d898ee9a8

That "#regzbot report" will be new and make it more obvious to users
what regzbot should consider to be the report (e.g. what Link:/Closes:
tags later in commits fixing the issue will link to). You used "#regzbot
introduced: 0a3d898ee9a8 ^" and due to the "^" it assumed the start of
this thread would be the report (side note: mixing that aspect into the
"introduced" command was a stupid idea anyway.).

That "#regzbot link:" will vanish as well (at least from the docs, it
will remain to be supported), as people use it wrong in various
different ways: for duplicates, reports (like your did), patch
submissions fixing the issue (then 'regzbot monitor' should have been
used) among others. Which is totally understandable now that I look at
it. That's why it will be replaced by "#regzbot related: <url>" to avoid
any connection with the Link: tag used in commits; for duplicates
"#regzbot dup:" will stay around.

>> Great, thx. Hope it reached mainline soon. Maybe once it's there you or
>> I should tell Greg to pick this up quickly for stable given that it
>> apparently "might affect quite a few people".
> I'll try to remember that but the thing is that I don't really follow
> stable releases.

Let me do it, it's easy for me. And FWIW, I don't even follow the stable
releases for that, I just drop Greg a mail when I notice the patch
reached mainline through the weekly net merge. He'll take care of the rest.

> I wish there would be a person who could follow stable
> releases from wireless perspective and make sure everything is ok there.

Maybe at some point regression tracking can help somewhat with that. But
I still have to fix a few things to make people use it and scale it up.

Side note: some people seem to have gotten the impression that I care a
lot about *all* stable/longterm kernels. Let me use this opportunity to
say that it's not really the case. I fully understand and respect that
those series are a somewhat separate thing some developers don't want to
be involved in (especially the older trees). But the thing is: the
latest stable tree is what we tell users to use -- and something quite a
few important distros ship as their regular kernel these days. That's
why I take special care of regression that found there.

Ciao, Thorsten