Re: Linux 7.1-rc3 regression (Bluetooth)

On 5/15/26 09:43, [email protected] wrote:
> On 15-May-26 07:37, Greg KH wrote:
>> On Fri, May 15, 2026 at 04:26:38AM +0200, August Wikerfors wrote:
>>> On 2026-05-11 08:30, Thorsten Leemhuis wrote:
>>>> On 5/11/26 07:17, [email protected] wrote:
>>>>> I upgrade 7.1-rc2 to 7.1-rc3. After that bluetooth  didn't start
>>>>> hci0: Failed to send wmt func ctrl (-22)
>>>>> My fix was to revert commit 634a4408c0615c523cf7531790f4f14a422b9206
>>>> Thx for your report. FWIW, there are two proposed fixed for this change
>>>> floating around:
>>>> https://lore.kernel.org/all/[email protected]/
>>>> https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
>>> [...]
>>> FYI the commit that caused this regression was backported to the latest
>>> stable releases (6.12.88, 6.18.30 and 7.0.7). I encountered it after
>>> [...]
>>> As a side note, it is unfortunate that there does not seem to be a
>>> process to prevent patches that are known to cause regressions from
>>> being backported to stable releases. As far as I can tell, this was
>>> added to regzbot tracking [3] a day before the culprit was queued for
>>> stable [4], so such a process could have prevented this regression in
>>> stable releases.
>> You can email stable@vger to let us know to drop a patch, or when the
>> -rcs are released, respond to the offending patch in that list.  THat's
>> why we have -rc releases!
> 
> That relies on someone actively intervening in the process though,
> I wonder if it would be an idea to have some CI which checks patches
> in stable RC releases vs regzbot tracking?
> 
> This assumes tegzbot tracking includes the mainline git hash of
> commits causing the regression (if/once known).
This is the case. And the idea to let regzbot help with preventing what
happened here is not new and even written on a todo list. The rough plan
was to let regzbot just export the list of mainline commit-ids with
unresolved regressions (together with a link to regzbot's webui with
more details) -- then all Greg would need to do is something like "curl
example.org/unresoved_regressions.txt | grep 1f2e3d4c5b6a" in his apply
script to notice potential problems.

That was how I envisioned things might be good for Greg -- of course
before implementing that I would have talked to him about it. But
regzbot development stalled for about two years due to lack of funding;
we are currently ramping it up again[1], but it will take some time to
get things sorted, so this is likely not something we'll implement
tomorrow. :-(

[1]
https://kernelci.org/blog/2026/05/04/regzbot-joins-kernelci-strengthening-linux-kernel-regression-tracking/

Ciao, Thorsten