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