linux-kernel - Re: Linux regressions report for mainline [2024-02-25]

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: <f2eaf931-8488-48e3-b008-1cedeba24f12@leemhuis.info>
Date: Tue, 27 Feb 2024 12:56:30 +0100
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
 Linux regressions mailing list <regressions@...ts.linux.dev>
Subject: Re: Linux regressions report for mainline [2024-02-25]

On 26.02.24 18:33, Linus Torvalds wrote:
> On Sun, 25 Feb 2024 at 06:21, Linux regression tracking (Thorsten
> Leemhuis) <regressions@...mhuis.info> wrote:
>>
>> Sorry, forgot something: there is a patch to fix a ntfs3 build problem
>> that was posted 10+ days ago[1] that didn't get any reaction from the
>> ntfs3 maintainer at all. Given the history of occasional slow responses
>> for that subsystem I thought I'd let you know in case you want to pick
>> the fix up directly; but if you do, consider using v2 of the patch[2].
> 
> Ack. Picked up directly.

Thx!

BTW, let me quickly mention two somewhat tricky regressions where I'm
unsure if they are handled how you want them to be handled.

* Multiple users were changing the minimum power limit of their Radeon
graphic cards to reduce the power consumption. Since 1958946858a62b
("drm/amd/pm: Support for getting power1_cap_min value") [v6.7-rc1] they
are unable to go as low as before, as amdgpu now respects a lower-bound
power limit ignored earlier. For details see:
https://lore.kernel.org/regressions/ae64f04d-6e94-4da4-a740-78ea94e0552c@riadoklan.sk.eu.org/
https://gitlab.freedesktop.org/drm/amd/-/issues/3183
https://gitlab.freedesktop.org/drm/amd/-/issues/3137
https://gitlab.freedesktop.org/drm/amd/-/issues/2992#note_2247003

  There was the idea to introduce a module parameter (see the lore
discussion linked above) to allow users what they were able to do
before. The amdgpu developers don't want to go down that path.

* Mikhail Gavrilov reported decreased network outgoing performance
caused by f977f4c9301c8a ("xhci: add handler for only one interrupt
line") [v6.8-rc1]: down from ~97-110MB/sec to 66-70MB/sec. Turns out
this is caused by the network device and xhci (USB) drivers now sharing
interrupts:
https://lore.kernel.org/lkml/CABXGCsNnUfCCYVSb_-j-a-cAdONu1r6Fe8p2OtQ5op_wskOfpw@mail.gmail.com/

  Mathias Nyman said that "Mikhail got unlucky" and Tglx called it a
"unfortunate coincidence"; both do not see a need for fix.

In both cases I up to a point can totally understand the point of view
of the developers that handle the situation; at the same time I was
unsure if those situation are handled as you want them to be handled.
That's why I brought them up here. If I don't hear anything from you
I'll assume everything is fine the way it is and will stop tracking both
regressions.

Ciao, Thorsten