Linux regressions report for mainline [2024-03-24]

From: Regzbot (on behalf of Thorsten Leemhuis)
Date: Sun Mar 24 2024 - 11:16:21 EST


Hi Linus, here is a quick regressions report. I already added a handful
of regression from this cycle to the tracking (see below), but none of
those are really worrying I'd say.

There is one more: a fix for a KASAN splat is already in next since
Friday as 9ddd90c947da4e ("fs/9p: fix uaf in in
v9fs_stat2inode_dotl")[1]. I had hoped Eric would have sent it to you by
now because it apparently is somewhat annoying for the net
maintainers[2] and maybe other kernel developers that use virtme -- but
seems that it's not on the way to you yet. :-/ Sigh. This "regression
fixes are ready at have been in next, but maintainers don't send them to
Linus before the next -rc" is sometimes slightly annoying from my point
of view...

[1] https://lore.kernel.org/all/20240202121531.2550018-1-lizhi.xu@xxxxxxxxxxxxx/
[2] https://lore.kernel.org/all/20240321182824.6f303e38@xxxxxxxxxx/

A few words on regressions from the 6.8 cycle that have an easy fix
available and are kinda stalled, in case you are interested:

* A change that came late in the previous cycle made Johan Hovold report
yet another 6.8 regression with the Lenovo ThinkPad X13s, this time
about a Bluetooth problem. He provided a revert to fix it - the BT
people replied, but then nothing happened for 10 days now afaics; will
prod tomorrow:
https://lore.kernel.org/lkml/20240314100103.GC6100@xxxxxxxxxxxxx/

* Two people reported CPU stalls on some Rockchip SOCs that a revert can
fix, but so far I could not convince the developer to set things in motion:
https://lore.kernel.org/lkml/ZYhQ2-OnjDgoqjvt@xxxxxxx/
https://lore.kernel.org/lkml/1553a526-6f28-4a68-88a8-f35bd22d9894@xxxxxxxxxxx/

* A fix for bogus lockdep warnings in network driver stmmac also is
making no progress, despite a Reviewed-by: from Eric and some prodding
from my side:
https://lore.kernel.org/lkml/20240306111157.29327-1-petr@xxxxxxxxxxx/

Ciao, Thorsten

---

Hi, this is regzbot, the Linux kernel regression tracking bot.

Currently I'm aware of 4 regressions in linux-mainline. Find the
current status below and the latest on the web:

https://linux-regtracking.leemhuis.info/regzbot/mainline/

Bye bye, hope to see you soon for the next report.
Regzbot (on behalf of Thorsten Leemhuis)


========================================================
current cycle (v6.8.. aka v6.8-post), culprit identified
========================================================


[ *NEW* ] x86/percpu: crashes in qemu with nosmp builds and Intel CPUs
----------------------------------------------------------------------
https://linux-regtracking.leemhuis.info/regzbot/regression/lore/e20d88d0-5fb9-4307-be67-88b04ae9a188@xxxxxxxxxxxx/
https://lore.kernel.org/lkml/e20d88d0-5fb9-4307-be67-88b04ae9a188@xxxxxxxxxxxx/

By Guenter Roeck; 8 days ago; 34 activities, latest 1 days ago.
Introduced in 71eb4893cfaf

Fix incoming:
* x86/cpu: Ensure that CPU info updates are propagated on UP
https://lore.kernel.org/regressions/07ba20d1-3c95-42b6-b566-f5c1980ffe16@xxxxxxxxxxxxx/


[ *NEW* ] mm: vmalloc: persistent "spinlock bad magic" message when booting s390 images with spinlock debugging enabled
-----------------------------------------------------------------------------------------------------------------------
https://linux-regtracking.leemhuis.info/regzbot/regression/lore/bbc242d5-3ab0-410f-a3b1-54a68e3e375f@xxxxxxxxxxxx/
https://lore.kernel.org/lkml/bbc242d5-3ab0-410f-a3b1-54a68e3e375f@xxxxxxxxxxxx/

By Guenter Roeck; 1 days ago; 3 activities, latest 1 days ago.
Introduced in 72210662c5a2

Recent activities from: Guenter Roeck (2), Uladzislau Rezki (1)

One patch associated with this regression:
* Re: [PATCH v3 07/11] mm: vmalloc: Offload free_vmap_area_lock lock
https://lore.kernel.org/lkml/Zf3V6B9f5o0H1LnE@pc636/
1 days ago, by Uladzislau Rezki


[ *NEW* ] Re: [PATCH] fs: Remove NTFS classic
---------------------------------------------
https://linux-regtracking.leemhuis.info/regzbot/regression/lore/Zf2zPf5TO5oYt3I3@xxxxxxxxxxxxxxxxxxxx/
https://lore.kernel.org/linux-fsdevel/Zf2zPf5TO5oYt3I3@xxxxxxxxxxxxxxxxxxxx/

By Johan Hovold; 1 days ago; 1 activities, latest 1 days ago.
Introduced in 7ffa8f3d3023

Recent activities from: Johan Hovold (1)


[ *NEW* ] SUNRPC: RFC 8009 encryption test fails
------------------------------------------------
https://linux-regtracking.leemhuis.info/regzbot/regression/lore/ZfxJZFwXqqurfet0@aion/
https://lore.kernel.org/linux-nfs/ZfxJZFwXqqurfet0@aion/

By Scott Mayhew; 3 days ago; 2 activities, latest 2 days ago.
Introduced in 561141dd4943

Recent activities from: Chuck Lever III (1), Scott Mayhew (1)


=============
End of report
=============

All regressions marked '[ *NEW* ]' were added since the previous report,
which can be found here:
https://lore.kernel.org/r/170947112079.436664.2969102323110743234@xxxxxxxxxxxxx

Thanks for your attention, have a nice day!

Regzbot, your hard working Linux kernel regression tracking robot


P.S.: Wanna know more about regzbot or how to use it to track regressions
for your subsystem? Then check out the getting started guide or the
reference documentation:

https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md

The short version: if you see a regression report you want to see
tracked, just send a reply to the report where you Cc
regressions@xxxxxxxxxxxxxxx with a line like this:

#regzbot introduced: v5.13..v5.14-rc1

If you want to fix a tracked regression, just do what is expected
anyway: add a 'Link:' tag with the url to the report, e.g.:

Link: https://lore.kernel.org/all/30th.anniversary.repost@xxxxxxxxxxxxxxxxxx/