Re: Linux 7.1-rc3 regression (Bluetooth)

Re: Linux 7.1-rc3 regression (Bluetooth)

[August Wikerfors]

On 2026-05-11 08:30, Thorsten Leemhuis wrote:
> On 5/11/26 07:17, markus.suvanto@gmail.com wrote:
>> Hello
>>
>> 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/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/
> https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
> 
> Given that this is the third revert within a short time-frame I wonder
> if we should fast-track a fix (once ready) to spare more users the pain
> of bisecting & reporting.

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
updating to 7.0.7 and can confirm that the patch from the second link
fixes it. That patch is now in the bluetooth tree as e3ac0d9f1a20
("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events") and a pull
request [1] has been made to the net tree. Unfortunately this seems to
have been a few hours too late to make it into the net pull request for
7.1-rc4 [2], so the fix might not get into mainline until next week.

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.

[1] https://lore.kernel.org/all/20260514172340.1515042-1-luiz.dentz@gmail.com/
[2] https://lore.kernel.org/all/20260514142703.267609-1-pabeni@redhat.com/
[3] https://lore.kernel.org/all/8a17737e-ba9b-4842-a429-c4eab3abcdec@leemhuis.info/
[4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=7780f283d14c8c6bf40fe9262219ad821a5dae80

Regards,
August Wikerfors

Re: Linux 7.1-rc3 regression (Bluetooth)

[Greg KH]

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, markus.suvanto@gmail.com wrote:
> > > Hello
> > > 
> > > 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/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/
> > https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
> > 
> > Given that this is the third revert within a short time-frame I wonder
> > if we should fast-track a fix (once ready) to spare more users the pain
> > of bisecting & reporting.
> 
> 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
> updating to 7.0.7 and can confirm that the patch from the second link
> fixes it. That patch is now in the bluetooth tree as e3ac0d9f1a20
> ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events") and a pull
> request [1] has been made to the net tree. Unfortunately this seems to
> have been a few hours too late to make it into the net pull request for
> 7.1-rc4 [2], so the fix might not get into mainline until next week.
> 
> 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!

thanks,

greg k-h

Re: Linux 7.1-rc3 regression (Bluetooth)

[johannes.goede]

Hi,

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, markus.suvanto@gmail.com wrote:
>>>> Hello
>>>>
>>>> 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/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/
>>> https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
>>>
>>> Given that this is the third revert within a short time-frame I wonder
>>> if we should fast-track a fix (once ready) to spare more users the pain
>>> of bisecting & reporting.
>>
>> 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
>> updating to 7.0.7 and can confirm that the patch from the second link
>> fixes it. That patch is now in the bluetooth tree as e3ac0d9f1a20
>> ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events") and a pull
>> request [1] has been made to the net tree. Unfortunately this seems to
>> have been a few hours too late to make it into the net pull request for
>> 7.1-rc4 [2], so the fix might not get into mainline until next week.
>>
>> 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).

Regards,

Hans

Re: Linux 7.1-rc3 regression (Bluetooth)

[Thorsten Leemhuis]

On 5/15/26 09:43, johannes.goede@oss.qualcomm.com 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, markus.suvanto@gmail.com 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/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/
>>>> 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