netdev - Re: Regression are sometimes merged slowly, maybe optimize the downstream interaction?

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]

Message-ID: <301a964e-2db1-6bb6-ffac-9077d8a119ff@leemhuis.info>
Date:   Tue, 1 Mar 2022 15:03:56 +0100
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Steffen Klassert <steffen.klassert@...unet.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>
Subject: Re: Regression are sometimes merged slowly, maybe optimize the
 downstream interaction?

On 01.03.22 14:26, Steffen Klassert wrote:
> On Tue, Mar 01, 2022 at 11:06:14AM +0100, Thorsten Leemhuis wrote:
>> On 28.02.22 18:46, Jakub Kicinski wrote:
>>> On Mon, 28 Feb 2022 14:45:47 +0100 Thorsten Leemhuis wrote:
> [...]
>>>> Often the fixes progress slowly due to the habits of the downstream
>>>> maintainers -- some for example are imho not asking you often enough to
>>>> pull fixes. I guess that might need to be discussed down the road as
>>>> well, but there is something else that imho needs to be addressed first.
>>
>> To give an example, but fwiw: that is in no way special, I've seen
>> similar turn of events for a few other regressions fixes in sub-tree of
>> net, so it really is just meant as an example for a general issue (sorry
>> Steffen).
> No problem.

Great, thx!

>>
>> See this fix:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=master&id=a6d95c5a628a09be129f25d5663a7e9db8261f51
>>
>> The regression was introduced in 5.14-rc1 and the fix was posted on
>> 2022-01-14, so 46 days ago.
> Let me give some background on this issue. [...]

thx for this, from the outside it's often hard to grasp how bad a
regression is, that's why I handle most of them the same way.
> This issue has already a long history and never really worked
> for all corner cases. That's why I was not in hurry with it at
> all.

Which I guess is fine. And if I had been under the the impression that
it was urgent I would have spoken up a few weeks ago when I asked when
the fix was going to get merged.

> Btw. how do you pick the regressions you are tracking? Why
> this issue and not the many others?

Some people already get regzbot directly involved to make sure their
report doesn't fall through the cracks.

I add most to the tracking that are CCed to the regressions list.

I also run a search for the word "regression" on lore and look at new
bugzilla tickets after a week. I add most of the regression reports I
find that way, but sometimes decide not doing so -- for example if the
fix already is on its way or if the regression is reported by a kernel
developer that knows to keep an eye on things.

Not perfect (just like regzbot), but you have to start somewhere.
> What is the aim of your tracking? Is it to make sure a regression
> fix will hit the manline, or/and the stable trees?

To ensure no reported regression falls through the cracks; the focus
currently is on mainline, but I keep any eye on stable as well.

Ciao, Thorsten