linux-kernel - Re: Problems with csum_partial with misaligned buffers on sh4 platform

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, 18 Mar 2024 16:58:44 +0100
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@...mhuis.info>
To: Guenter Roeck <linux@...ck-us.net>,
 Linux regressions mailing list <regressions@...ts.linux.dev>,
 Yoshinori Sato <ysato@...rs.sourceforge.jp>
Cc: Rich Felker <dalias@...c.org>,
 John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
 linux-sh@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Problems with csum_partial with misaligned buffers on sh4
 platform

On 18.03.24 16:32, Guenter Roeck wrote:
> On 3/18/24 08:04, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 11.03.24 18:04, Guenter Roeck wrote:
>>> On Sat, Feb 10, 2024 at 07:12:39AM -0800, Guenter Roeck wrote:
>>>>
>>>> when running checksum unit tests on sh4 qemu emulations, I get the
>>>> following
>>>> errors.
>>>
>>> Adding to regression tracker.
>>>
>>> #regzbot ^introduced cadc4e1a2b4d2
>>
>> Hmmm, thx for that, but well, I'm a bit taken back and forth here. That
>> commit afaics is from v3.0-rc1 and Linus iirc at least once said
>> something along the lines of "a regression only reported after a long
>> time at some point becomes just a bug". I'd say that applies there,
>> which is why I'm wondering if tracking this really is worth it.
> 
> Not my call to make. I'll keep in mind to not add "bugs" to the regression
> tracker in the future.

>From my side there is no need for you to keep that in mind, as "somewhat
added this regression to the tracking" might be something that will
occasionally make a developer finally fix the problem -- which is why I
waited a few days with today's reply. :-D

> Feel free to drop.

Let me do that:

#regzbot inconclusive: really old regression

> For my understanding, what is "a long time" ?

That is a good question and I guess the answer like so often in kernel
land depends on the regression in question. :-/ Also note that that
"iirc" really was meant like it, as I might misremember. I just checked
and found two related quotes, but the situations are somewhat different:

https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/
"""
And yes, I do consider "regression in an earlier release" to be a
regression that needs fixing.

There's obviously a time limit: if that "regression in an earlier
release" was a year or more ago, and just took forever for people to
notice, and it had semantic changes that now mean that fixing the
regression could cause a _new_ regression, then that can cause me to
go "Oh, now the new semantics are what we have to live with".
"""

And also:
https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/
"""
And obviously, if users take years to even notice that something
broke, or if we have sane ways to work around the breakage that
doesn't make for too much trouble for users (ie "ok, there are a
handful of users, and they can use a kernel command line to work
around it" kind of things) we've also been a bit less strict.
"""

Ciao, Thorsten