[GIT PULL] bluetooth 2026-05-14

[GIT PULL] bluetooth 2026-05-14

[Luiz Augusto von Dentz]

The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:

  net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14

for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:

  Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)

----------------------------------------------------------------
bluetooth pull request for net:

 - af_bluetooth: serialize accept_q access
 - L2CAP: ecred_reconfigure: send packed pdu, not stack pointer
 - btmtk: accept too short WMT FUNC_CTRL events
 - hci_qca: Convert timeout from jiffies to ms

----------------------------------------------------------------
Jiexun Wang (1):
      Bluetooth: serialize accept_q access

Michael Bommarito (1):
      Bluetooth: L2CAP: ecred_reconfigure: send packed pdu, not stack pointer

Pauli Virtanen (1):
      Bluetooth: btmtk: accept too short WMT FUNC_CTRL events

Shuai Zhang (1):
      Bluetooth: hci_qca: Convert timeout from jiffies to ms

 drivers/bluetooth/btmtk.c         |  4 +-
 drivers/bluetooth/hci_qca.c       | 33 +++++++--------
 include/net/bluetooth/bluetooth.h |  1 +
 net/bluetooth/af_bluetooth.c      | 87 +++++++++++++++++++++++++++++----------
 net/bluetooth/l2cap_core.c        |  2 +-
 5 files changed, 85 insertions(+), 42 deletions(-)

Re: [GIT PULL] bluetooth 2026-05-14

[Thorsten Leemhuis]

[+Linus +Greg]

On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> 
>   net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> 
> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> 
>   Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)

It seems this PR sadly came too late for this week's net PR to mainline
that was merged yesterday.

TWIMC, from my point of view, it would be great if we somehow could
still get the changes from this PR or at least the btmtk fix it
contains[1] to mainline this week before -rc4, as it is fixing a
regression known since 2026-04-24 that at least five people encountered
with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
validate WMT event SKB length before struct access") [006b9943b982 in
-next].

Another reason: Greg a few hours ago backported the culprit for the
regression to v7.0.7, v6.18.30, and v6.12.88, which led to a bunch of
other reports coming in[3]. Greg could, of course, revert it, but
usually he prefers to just merge the fix. But of course the fix must
first hit mainline (or at least -next) -- and that might only happen
next Thursday, as there usually is only one net PR per week. Luiz even
wanted to "expedite a PR to have it fixed asap"[4], but that didn't work
out afaics, hence this mail.

Ciao, Thorsten

[1] btmtk: accept too short WMT FUNC_CTRL events – also available here:
https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/

[2]
https://lore.kernel.org/lkml/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/
https://lore.kernel.org/lkml/f652d5d9841a9b7c100dd19ee97c86099f580724.camel@gmail.com/
https://bugzilla.kernel.org/show_bug.cgi?id=221511
https://lore.kernel.org/lkml/20260514-bluetooh-fix-mt7922-v1-1-499c878af1e5@zohomail.in/
https://lore.kernel.org/lkml/20260514-bluetooh-fix-mt7922-v1-1-499c878af1e5@zohomail.in/
(+ one more report in a Fedora kernel chatroom)

[3]
https://bugzilla.kernel.org/show_bug.cgi?id=221521
https://lore.kernel.org/lkml/51b55b97-615b-4f5e-b454-df646f4058b7@augustwikerfors.se/
+ a four more people in
https://bodhi.fedoraproject.org/updates/FEDORA-2026-6b173ffc2a#comment-4646633

[4]
https://lore.kernel.org/all/CABBYNZ+FfhYtU2=J-V4pjKf_vKV=Y5LhVhxS_epKe-qaUUt8_g@mail.gmail.com/


> ----------------------------------------------------------------
> bluetooth pull request for net:
> 
>  - af_bluetooth: serialize accept_q access
>  - L2CAP: ecred_reconfigure: send packed pdu, not stack pointer
>  - btmtk: accept too short WMT FUNC_CTRL events
>  - hci_qca: Convert timeout from jiffies to ms
> 
> ----------------------------------------------------------------
> Jiexun Wang (1):
>       Bluetooth: serialize accept_q access
> 
> Michael Bommarito (1):
>       Bluetooth: L2CAP: ecred_reconfigure: send packed pdu, not stack pointer
> 
> Pauli Virtanen (1):
>       Bluetooth: btmtk: accept too short WMT FUNC_CTRL events
> 
> Shuai Zhang (1):
>       Bluetooth: hci_qca: Convert timeout from jiffies to ms
> 
>  drivers/bluetooth/btmtk.c         |  4 +-
>  drivers/bluetooth/hci_qca.c       | 33 +++++++--------
>  include/net/bluetooth/bluetooth.h |  1 +
>  net/bluetooth/af_bluetooth.c      | 87 +++++++++++++++++++++++++++++----------
>  net/bluetooth/l2cap_core.c        |  2 +-
>  5 files changed, 85 insertions(+), 42 deletions(-)
> 

Re: [GIT PULL] bluetooth 2026-05-14

[patchwork-bot+netdevbpf]

Hello:

This pull request was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Thu, 14 May 2026 13:23:40 -0400 you wrote:
> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> 
>   net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> 
> [...]

Here is the summary with links:
  - [GIT,PULL] bluetooth 2026-05-14
    https://git.kernel.org/netdev/net/c/23f3b04f157c

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [GIT PULL] bluetooth 2026-05-14

[Thorsten Leemhuis]

On 5/15/26 17:10, Thorsten Leemhuis wrote:
> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
>
>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
>>   net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
>>
>> are available in the Git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
>>
>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
>>
>>   Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> 
> It seems this PR sadly came too late for this week's net PR to mainline
> that was merged yesterday.
> 
> TWIMC, from my point of view, it would be great if we somehow could
> still get the changes from this PR or at least the btmtk fix it
> contains[1] to mainline this week before -rc4, as it is fixing a
> regression known since 2026-04-24 that at least five people encountered
> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> validate WMT event SKB length before struct access") [006b9943b982 in
> -next].

Greg, Sasha, that [1] fix I was talking about now reached -next as
162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
events") and will likely hit mainline on Thursday or so with the weekly
-net PR to -mainline. If that's good enough for you, I'd say it would be
good to pick this up for the next round of stable kernels.

Ciao, Thorsten

P.S.: Side note, in case anyone cares: this regression meanwhile was
reported at least 14 times by now (only counting upstream reports, there
are many more in various downstreams).

> Another reason: Greg a few hours ago backported the culprit for the
> regression to v7.0.7, v6.18.30, and v6.12.88, which led to a bunch of
> other reports coming in[3]. Greg could, of course, revert it, but
> usually he prefers to just merge the fix. But of course the fix must
> first hit mainline (or at least -next) -- and that might only happen
> next Thursday, as there usually is only one net PR per week. Luiz even
> wanted to "expedite a PR to have it fixed asap"[4], but that didn't work
> out afaics, hence this mail.
> 
> Ciao, Thorsten
> 
> [1] btmtk: accept too short WMT FUNC_CTRL events – also available here:
> https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
> 
> [2]
> https://lore.kernel.org/lkml/20260508173121.27526-1-mikhail.v.gavrilov@gmail.com/
> https://lore.kernel.org/lkml/f652d5d9841a9b7c100dd19ee97c86099f580724.camel@gmail.com/
> https://bugzilla.kernel.org/show_bug.cgi?id=221511
> https://lore.kernel.org/lkml/20260514-bluetooh-fix-mt7922-v1-1-499c878af1e5@zohomail.in/
> https://lore.kernel.org/lkml/20260514-bluetooh-fix-mt7922-v1-1-499c878af1e5@zohomail.in/
> (+ one more report in a Fedora kernel chatroom)
> 
> [3]
> https://bugzilla.kernel.org/show_bug.cgi?id=221521
> https://lore.kernel.org/lkml/51b55b97-615b-4f5e-b454-df646f4058b7@augustwikerfors.se/
> + a four more people in
> https://bodhi.fedoraproject.org/updates/FEDORA-2026-6b173ffc2a#comment-4646633
> 
> [4]
> https://lore.kernel.org/all/CABBYNZ+FfhYtU2=J-V4pjKf_vKV=Y5LhVhxS_epKe-qaUUt8_g@mail.gmail.com/
> 
> 
>> ----------------------------------------------------------------
>> bluetooth pull request for net:
>>
>>  - af_bluetooth: serialize accept_q access
>>  - L2CAP: ecred_reconfigure: send packed pdu, not stack pointer
>>  - btmtk: accept too short WMT FUNC_CTRL events
>>  - hci_qca: Convert timeout from jiffies to ms
>>
>> ----------------------------------------------------------------
>> Jiexun Wang (1):
>>       Bluetooth: serialize accept_q access
>>
>> Michael Bommarito (1):
>>       Bluetooth: L2CAP: ecred_reconfigure: send packed pdu, not stack pointer
>>
>> Pauli Virtanen (1):
>>       Bluetooth: btmtk: accept too short WMT FUNC_CTRL events
>>
>> Shuai Zhang (1):
>>       Bluetooth: hci_qca: Convert timeout from jiffies to ms
>>
>>  drivers/bluetooth/btmtk.c         |  4 +-
>>  drivers/bluetooth/hci_qca.c       | 33 +++++++--------
>>  include/net/bluetooth/bluetooth.h |  1 +
>>  net/bluetooth/af_bluetooth.c      | 87 +++++++++++++++++++++++++++++----------
>>  net/bluetooth/l2cap_core.c        |  2 +-
>>  5 files changed, 85 insertions(+), 42 deletions(-)
>>
> 

Re: [GIT PULL] bluetooth 2026-05-14

[Greg KH]

On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> >
> >> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> >>   net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> >>
> >> are available in the Git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> >>
> >> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> >>
> >>   Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > 
> > It seems this PR sadly came too late for this week's net PR to mainline
> > that was merged yesterday.
> > 
> > TWIMC, from my point of view, it would be great if we somehow could
> > still get the changes from this PR or at least the btmtk fix it
> > contains[1] to mainline this week before -rc4, as it is fixing a
> > regression known since 2026-04-24 that at least five people encountered
> > with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > validate WMT event SKB length before struct access") [006b9943b982 in
> > -next].
> 
> Greg, Sasha, that [1] fix I was talking about now reached -next as
> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> events") and will likely hit mainline on Thursday or so with the weekly
> -net PR to -mainline. If that's good enough for you, I'd say it would be
> good to pick this up for the next round of stable kernels.

That "Fixes:" tag is referring to something that is also not in any
tree, but that commit does have a cc: stable in it.  So do we need both
of these:

041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")

Or just one?

confused,

greg k-h

Re: [GIT PULL] bluetooth 2026-05-14

[Thorsten Leemhuis]

On 5/19/26 12:30, Greg KH wrote:
> On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
>> On 5/15/26 17:10, Thorsten Leemhuis wrote:
>>> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
>>>
>>>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
>>>>   net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
>>>>
>>>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
>>>>
>>>>   Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
>>>
>>> It seems this PR sadly came too late for this week's net PR to mainline
>>> that was merged yesterday.
>>>
>>> TWIMC, from my point of view, it would be great if we somehow could
>>> still get the changes from this PR or at least the btmtk fix it
>>> contains[1] to mainline this week before -rc4, as it is fixing a
>>> regression known since 2026-04-24 that at least five people encountered
>>> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
>>> validate WMT event SKB length before struct access") [006b9943b982 in
>>> -next].
>>
>> Greg, Sasha, that [1] fix I was talking about now reached -next as
>> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
>> events") and will likely hit mainline on Thursday or so with the weekly
>> -net PR to -mainline. If that's good enough for you, I'd say it would be
>> good to pick this up for the next round of stable kernels.
> 
> That "Fixes:" tag is referring to something that is also not in any
> tree, but that commit does have a cc: stable in it.  So do we need both
> of these:

Valid question, as yes, there is a slight mixup here:

> 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")

That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
-next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
btmtk: validate WMT event SKB length before struct access") -- the one
that is causing the regression that I want to get fixed. So we now only
need:

> 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")

thx!

Ciao, Thorsten

Re: [GIT PULL] bluetooth 2026-05-14

[Greg KH]

On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> On 5/19/26 12:30, Greg KH wrote:
> > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> >> On 5/15/26 17:10, Thorsten Leemhuis wrote:
> >>> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> >>>
> >>>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> >>>>   net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> >>>>
> >>>> are available in the Git repository at:
> >>>>
> >>>>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> >>>>
> >>>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> >>>>
> >>>>   Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> >>>
> >>> It seems this PR sadly came too late for this week's net PR to mainline
> >>> that was merged yesterday.
> >>>
> >>> TWIMC, from my point of view, it would be great if we somehow could
> >>> still get the changes from this PR or at least the btmtk fix it
> >>> contains[1] to mainline this week before -rc4, as it is fixing a
> >>> regression known since 2026-04-24 that at least five people encountered
> >>> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> >>> validate WMT event SKB length before struct access") [006b9943b982 in
> >>> -next].
> >>
> >> Greg, Sasha, that [1] fix I was talking about now reached -next as
> >> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> >> events") and will likely hit mainline on Thursday or so with the weekly
> >> -net PR to -mainline. If that's good enough for you, I'd say it would be
> >> good to pick this up for the next round of stable kernels.
> > 
> > That "Fixes:" tag is referring to something that is also not in any
> > tree, but that commit does have a cc: stable in it.  So do we need both
> > of these:
> 
> Valid question, as yes, there is a slight mixup here:
> 
> > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> 
> That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> btmtk: validate WMT event SKB length before struct access") -- the one
> that is causing the regression that I want to get fixed. So we now only
> need:
> 
> > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")

Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
nightmare to track over time, ugh.

I'll go queue this up now, thanks.

greg k-h

Re: [GIT PULL] bluetooth 2026-05-14

[Luiz Augusto von Dentz]

Hi Greg,

On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > On 5/19/26 12:30, Greg KH wrote:
> > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > >> On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > >>> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > >>>
> > >>>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > >>>>   net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > >>>>
> > >>>> are available in the Git repository at:
> > >>>>
> > >>>>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > >>>>
> > >>>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > >>>>
> > >>>>   Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > >>>
> > >>> It seems this PR sadly came too late for this week's net PR to mainline
> > >>> that was merged yesterday.
> > >>>
> > >>> TWIMC, from my point of view, it would be great if we somehow could
> > >>> still get the changes from this PR or at least the btmtk fix it
> > >>> contains[1] to mainline this week before -rc4, as it is fixing a
> > >>> regression known since 2026-04-24 that at least five people encountered
> > >>> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > >>> validate WMT event SKB length before struct access") [006b9943b982 in
> > >>> -next].
> > >>
> > >> Greg, Sasha, that [1] fix I was talking about now reached -next as
> > >> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > >> events") and will likely hit mainline on Thursday or so with the weekly
> > >> -net PR to -mainline. If that's good enough for you, I'd say it would be
> > >> good to pick this up for the next round of stable kernels.
> > >
> > > That "Fixes:" tag is referring to something that is also not in any
> > > tree, but that commit does have a cc: stable in it.  So do we need both
> > > of these:
> >
> > Valid question, as yes, there is a slight mixup here:
> >
> > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> >
> > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > btmtk: validate WMT event SKB length before struct access") -- the one
> > that is causing the regression that I want to get fixed. So we now only
> > need:
> >
> > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
>
> Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> nightmare to track over time, ugh.

Hmm, did we get the wrong hash or something? Usually, that would show
up in the verify-fixes.sh, but perhaps it didn't capture it this time
for some reason, perhaps I'm running an outdated version or something
similar.

I will try making the Bluetooth CI run the verify-fixes.sh to detect
this sort of issue early on.

> I'll go queue this up now, thanks.
>
> greg k-h



-- 
Luiz Augusto von Dentz

Re: [GIT PULL] bluetooth 2026-05-14

[Greg KH]

On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
> Hi Greg,
> 
> On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > > On 5/19/26 12:30, Greg KH wrote:
> > > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > > >> On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > > >>> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > > >>>
> > > >>>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > > >>>>   net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > > >>>>
> > > >>>> are available in the Git repository at:
> > > >>>>
> > > >>>>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > > >>>>
> > > >>>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > > >>>>
> > > >>>>   Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > > >>>
> > > >>> It seems this PR sadly came too late for this week's net PR to mainline
> > > >>> that was merged yesterday.
> > > >>>
> > > >>> TWIMC, from my point of view, it would be great if we somehow could
> > > >>> still get the changes from this PR or at least the btmtk fix it
> > > >>> contains[1] to mainline this week before -rc4, as it is fixing a
> > > >>> regression known since 2026-04-24 that at least five people encountered
> > > >>> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > > >>> validate WMT event SKB length before struct access") [006b9943b982 in
> > > >>> -next].
> > > >>
> > > >> Greg, Sasha, that [1] fix I was talking about now reached -next as
> > > >> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > > >> events") and will likely hit mainline on Thursday or so with the weekly
> > > >> -net PR to -mainline. If that's good enough for you, I'd say it would be
> > > >> good to pick this up for the next round of stable kernels.
> > > >
> > > > That "Fixes:" tag is referring to something that is also not in any
> > > > tree, but that commit does have a cc: stable in it.  So do we need both
> > > > of these:
> > >
> > > Valid question, as yes, there is a slight mixup here:
> > >
> > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> > >
> > > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > > btmtk: validate WMT event SKB length before struct access") -- the one
> > > that is causing the regression that I want to get fixed. So we now only
> > > need:
> > >
> > > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
> >
> > Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> > nightmare to track over time, ugh.
> 
> Hmm, did we get the wrong hash or something? Usually, that would show
> up in the verify-fixes.sh, but perhaps it didn't capture it this time
> for some reason, perhaps I'm running an outdated version or something
> similar.

Something went wrong if we ended up with a patch in the stable trees,
yet this fix is referring to it as a different git sha.  Don't know
where the disconnect happend :(

thanks,

greg k-h

Re: [GIT PULL] bluetooth 2026-05-14

[Luiz Augusto von Dentz]

Hi Greg,

On Tue, May 19, 2026 at 11:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
> > Hi Greg,
> >
> > On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > > > On 5/19/26 12:30, Greg KH wrote:
> > > > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > > > >> On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > > > >>> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > > > >>>
> > > > >>>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > > > >>>>   net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > > > >>>>
> > > > >>>> are available in the Git repository at:
> > > > >>>>
> > > > >>>>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > > > >>>>
> > > > >>>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > > > >>>>
> > > > >>>>   Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > > > >>>
> > > > >>> It seems this PR sadly came too late for this week's net PR to mainline
> > > > >>> that was merged yesterday.
> > > > >>>
> > > > >>> TWIMC, from my point of view, it would be great if we somehow could
> > > > >>> still get the changes from this PR or at least the btmtk fix it
> > > > >>> contains[1] to mainline this week before -rc4, as it is fixing a
> > > > >>> regression known since 2026-04-24 that at least five people encountered
> > > > >>> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > > > >>> validate WMT event SKB length before struct access") [006b9943b982 in
> > > > >>> -next].
> > > > >>
> > > > >> Greg, Sasha, that [1] fix I was talking about now reached -next as
> > > > >> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > > > >> events") and will likely hit mainline on Thursday or so with the weekly
> > > > >> -net PR to -mainline. If that's good enough for you, I'd say it would be
> > > > >> good to pick this up for the next round of stable kernels.
> > > > >
> > > > > That "Fixes:" tag is referring to something that is also not in any
> > > > > tree, but that commit does have a cc: stable in it.  So do we need both
> > > > > of these:
> > > >
> > > > Valid question, as yes, there is a slight mixup here:
> > > >
> > > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> > > >
> > > > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > > > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > > > btmtk: validate WMT event SKB length before struct access") -- the one
> > > > that is causing the regression that I want to get fixed. So we now only
> > > > need:
> > > >
> > > > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
> > >
> > > Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> > > nightmare to track over time, ugh.
> >
> > Hmm, did we get the wrong hash or something? Usually, that would show
> > up in the verify-fixes.sh, but perhaps it didn't capture it this time
> > for some reason, perhaps I'm running an outdated version or something
> > similar.
>
> Something went wrong if we ended up with a patch in the stable trees,
> yet this fix is referring to it as a different git sha.  Don't know
> where the disconnect happend :(

041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before
struct access")

I don't have that in any of our tree either, this is actually
634a4408c061 on all trees in the chain:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=634a4408c061
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=634a4408c061
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=634a4408c061

Or actually that was the hash before it got rebased on bluetooth-next tree:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=041e88fb0c08

But I didn't send the PR from that three so perhaps somebody else sent
it to stable with the wrong fixes tag?

> thanks,
>
> greg k-h



-- 
Luiz Augusto von Dentz

Re: [GIT PULL] bluetooth 2026-05-14

[August Wikerfors]

On 2026-05-19 17:49, Luiz Augusto von Dentz wrote:
> Hi Greg,
> 
> On Tue, May 19, 2026 at 11:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>>
>> On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
>>> Hi Greg,
>>>
>>> On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>>>>
>>>> On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
>>>>> On 5/19/26 12:30, Greg KH wrote:
>>>>>> On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
>>>>>>> On 5/15/26 17:10, Thorsten Leemhuis wrote:
>>>>>>>> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
>>>>>>>>
>>>>>>>>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
>>>>>>>>>    net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
>>>>>>>>>
>>>>>>>>> are available in the Git repository at:
>>>>>>>>>
>>>>>>>>>    git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
>>>>>>>>>
>>>>>>>>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
>>>>>>>>>
>>>>>>>>>    Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
>>>>>>>>
>>>>>>>> It seems this PR sadly came too late for this week's net PR to mainline
>>>>>>>> that was merged yesterday.
>>>>>>>>
>>>>>>>> TWIMC, from my point of view, it would be great if we somehow could
>>>>>>>> still get the changes from this PR or at least the btmtk fix it
>>>>>>>> contains[1] to mainline this week before -rc4, as it is fixing a
>>>>>>>> regression known since 2026-04-24 that at least five people encountered
>>>>>>>> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
>>>>>>>> validate WMT event SKB length before struct access") [006b9943b982 in
>>>>>>>> -next].
>>>>>>>
>>>>>>> Greg, Sasha, that [1] fix I was talking about now reached -next as
>>>>>>> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
>>>>>>> events") and will likely hit mainline on Thursday or so with the weekly
>>>>>>> -net PR to -mainline. If that's good enough for you, I'd say it would be
>>>>>>> good to pick this up for the next round of stable kernels.
>>>>>>
>>>>>> That "Fixes:" tag is referring to something that is also not in any
>>>>>> tree, but that commit does have a cc: stable in it.  So do we need both
>>>>>> of these:
>>>>>
>>>>> Valid question, as yes, there is a slight mixup here:
>>>>>
>>>>>> 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
>>>>>
>>>>> That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
>>>>> -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
>>>>> btmtk: validate WMT event SKB length before struct access") -- the one
>>>>> that is causing the regression that I want to get fixed. So we now only
>>>>> need:
>>>>>
>>>>>> 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
>>>>
>>>> Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
>>>> nightmare to track over time, ugh.
>>>
>>> Hmm, did we get the wrong hash or something? Usually, that would show
>>> up in the verify-fixes.sh, but perhaps it didn't capture it this time
>>> for some reason, perhaps I'm running an outdated version or something
>>> similar.
>>
>> Something went wrong if we ended up with a patch in the stable trees,
>> yet this fix is referring to it as a different git sha.  Don't know
>> where the disconnect happend :(
> 
> 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before
> struct access")
> 
> I don't have that in any of our tree either, this is actually
> 634a4408c061 on all trees in the chain:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=634a4408c061
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=634a4408c061
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=634a4408c061
> 
> Or actually that was the hash before it got rebased on bluetooth-next tree:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=041e88fb0c08
> 
> But I didn't send the PR from that three so perhaps somebody else sent
> it to stable with the wrong fixes tag?
I believe the confusion comes from "Bluetooth: btmtk: accept too short 
WMT FUNC_CTRL events" itself currently having different commit hashes in 
bluetooth (e3ac0d9f1a20) and bluetooth-next (162b1adeb057). The former 
correctly refers to "Bluetooth: btmtk: validate WMT event SKB length 
before struct access" as 634a4408c061 in the Fixes tag and was merged 
into net yesterday heading for 7.1-rc5. The latter still refers to it as 
041e88fb0c08. Both are now in next-20260519 but only the latter was in 
next-20260518 which was the latest at the time of Thorsten's message.

Greg, this means picking e3ac0d9f1a20 instead of 162b1adeb057 should 
result in a valid Fixes tag.

Regards,
August Wikerfors

Re: [GIT PULL] bluetooth 2026-05-14

[Greg KH]

On Tue, May 19, 2026 at 07:37:35PM +0200, August Wikerfors wrote:
> On 2026-05-19 17:49, Luiz Augusto von Dentz wrote:
> > Hi Greg,
> > 
> > On Tue, May 19, 2026 at 11:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > 
> > > On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
> > > > Hi Greg,
> > > > 
> > > > On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > 
> > > > > On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > > > > > On 5/19/26 12:30, Greg KH wrote:
> > > > > > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > > > > > > > On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > > > > > > > > On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > > > > > > > > 
> > > > > > > > > > The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > > > > > > > > >    net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > > > > > > > > > 
> > > > > > > > > > are available in the Git repository at:
> > > > > > > > > > 
> > > > > > > > > >    git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > > > > > > > > > 
> > > > > > > > > > for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > > > > > > > > > 
> > > > > > > > > >    Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > > > > > > > > 
> > > > > > > > > It seems this PR sadly came too late for this week's net PR to mainline
> > > > > > > > > that was merged yesterday.
> > > > > > > > > 
> > > > > > > > > TWIMC, from my point of view, it would be great if we somehow could
> > > > > > > > > still get the changes from this PR or at least the btmtk fix it
> > > > > > > > > contains[1] to mainline this week before -rc4, as it is fixing a
> > > > > > > > > regression known since 2026-04-24 that at least five people encountered
> > > > > > > > > with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > > > > > > > > validate WMT event SKB length before struct access") [006b9943b982 in
> > > > > > > > > -next].
> > > > > > > > 
> > > > > > > > Greg, Sasha, that [1] fix I was talking about now reached -next as
> > > > > > > > 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > > > > > > > events") and will likely hit mainline on Thursday or so with the weekly
> > > > > > > > -net PR to -mainline. If that's good enough for you, I'd say it would be
> > > > > > > > good to pick this up for the next round of stable kernels.
> > > > > > > 
> > > > > > > That "Fixes:" tag is referring to something that is also not in any
> > > > > > > tree, but that commit does have a cc: stable in it.  So do we need both
> > > > > > > of these:
> > > > > > 
> > > > > > Valid question, as yes, there is a slight mixup here:
> > > > > > 
> > > > > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> > > > > > 
> > > > > > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > > > > > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > > > > > btmtk: validate WMT event SKB length before struct access") -- the one
> > > > > > that is causing the regression that I want to get fixed. So we now only
> > > > > > need:
> > > > > > 
> > > > > > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
> > > > > 
> > > > > Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> > > > > nightmare to track over time, ugh.
> > > > 
> > > > Hmm, did we get the wrong hash or something? Usually, that would show
> > > > up in the verify-fixes.sh, but perhaps it didn't capture it this time
> > > > for some reason, perhaps I'm running an outdated version or something
> > > > similar.
> > > 
> > > Something went wrong if we ended up with a patch in the stable trees,
> > > yet this fix is referring to it as a different git sha.  Don't know
> > > where the disconnect happend :(
> > 
> > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before
> > struct access")
> > 
> > I don't have that in any of our tree either, this is actually
> > 634a4408c061 on all trees in the chain:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=634a4408c061
> > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=634a4408c061
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=634a4408c061
> > 
> > Or actually that was the hash before it got rebased on bluetooth-next tree:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=041e88fb0c08
> > 
> > But I didn't send the PR from that three so perhaps somebody else sent
> > it to stable with the wrong fixes tag?
> I believe the confusion comes from "Bluetooth: btmtk: accept too short WMT
> FUNC_CTRL events" itself currently having different commit hashes in
> bluetooth (e3ac0d9f1a20) and bluetooth-next (162b1adeb057). The former
> correctly refers to "Bluetooth: btmtk: validate WMT event SKB length before
> struct access" as 634a4408c061 in the Fixes tag and was merged into net
> yesterday heading for 7.1-rc5. The latter still refers to it as
> 041e88fb0c08. Both are now in next-20260519 but only the latter was in
> next-20260518 which was the latest at the time of Thorsten's message.
> 
> Greg, this means picking e3ac0d9f1a20 instead of 162b1adeb057 should result
> in a valid Fixes tag.

Ok, now done.  Be careful of duplicate commits in different branches
that are marked for backporting with different ids.  It can cause
massive confusion (i.e. don't be like the drm tree...)

thanks,

greg k-h

Re: [GIT PULL] bluetooth 2026-05-14

[Luiz Augusto von Dentz]

Hi Greg,

On Wed, May 20, 2026 at 8:47 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, May 19, 2026 at 07:37:35PM +0200, August Wikerfors wrote:
> > On 2026-05-19 17:49, Luiz Augusto von Dentz wrote:
> > > Hi Greg,
> > >
> > > On Tue, May 19, 2026 at 11:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
> > > > > Hi Greg,
> > > > >
> > > > > On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > > > > > > On 5/19/26 12:30, Greg KH wrote:
> > > > > > > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > > > > > > > > On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > > > > > > > > > On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > > > > > > > > >
> > > > > > > > > > > The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > > > > > > > > > >    net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > > > > > > > > > >
> > > > > > > > > > > are available in the Git repository at:
> > > > > > > > > > >
> > > > > > > > > > >    git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > > > > > > > > > >
> > > > > > > > > > > for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > > > > > > > > > >
> > > > > > > > > > >    Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > > > > > > > > >
> > > > > > > > > > It seems this PR sadly came too late for this week's net PR to mainline
> > > > > > > > > > that was merged yesterday.
> > > > > > > > > >
> > > > > > > > > > TWIMC, from my point of view, it would be great if we somehow could
> > > > > > > > > > still get the changes from this PR or at least the btmtk fix it
> > > > > > > > > > contains[1] to mainline this week before -rc4, as it is fixing a
> > > > > > > > > > regression known since 2026-04-24 that at least five people encountered
> > > > > > > > > > with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > > > > > > > > > validate WMT event SKB length before struct access") [006b9943b982 in
> > > > > > > > > > -next].
> > > > > > > > >
> > > > > > > > > Greg, Sasha, that [1] fix I was talking about now reached -next as
> > > > > > > > > 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > > > > > > > > events") and will likely hit mainline on Thursday or so with the weekly
> > > > > > > > > -net PR to -mainline. If that's good enough for you, I'd say it would be
> > > > > > > > > good to pick this up for the next round of stable kernels.
> > > > > > > >
> > > > > > > > That "Fixes:" tag is referring to something that is also not in any
> > > > > > > > tree, but that commit does have a cc: stable in it.  So do we need both
> > > > > > > > of these:
> > > > > > >
> > > > > > > Valid question, as yes, there is a slight mixup here:
> > > > > > >
> > > > > > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> > > > > > >
> > > > > > > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > > > > > > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > > > > > > btmtk: validate WMT event SKB length before struct access") -- the one
> > > > > > > that is causing the regression that I want to get fixed. So we now only
> > > > > > > need:
> > > > > > >
> > > > > > > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
> > > > > >
> > > > > > Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> > > > > > nightmare to track over time, ugh.
> > > > >
> > > > > Hmm, did we get the wrong hash or something? Usually, that would show
> > > > > up in the verify-fixes.sh, but perhaps it didn't capture it this time
> > > > > for some reason, perhaps I'm running an outdated version or something
> > > > > similar.
> > > >
> > > > Something went wrong if we ended up with a patch in the stable trees,
> > > > yet this fix is referring to it as a different git sha.  Don't know
> > > > where the disconnect happend :(
> > >
> > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before
> > > struct access")
> > >
> > > I don't have that in any of our tree either, this is actually
> > > 634a4408c061 on all trees in the chain:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=634a4408c061
> > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=634a4408c061
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=634a4408c061
> > >
> > > Or actually that was the hash before it got rebased on bluetooth-next tree:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=041e88fb0c08
> > >
> > > But I didn't send the PR from that three so perhaps somebody else sent
> > > it to stable with the wrong fixes tag?
> > I believe the confusion comes from "Bluetooth: btmtk: accept too short WMT
> > FUNC_CTRL events" itself currently having different commit hashes in
> > bluetooth (e3ac0d9f1a20) and bluetooth-next (162b1adeb057). The former
> > correctly refers to "Bluetooth: btmtk: validate WMT event SKB length before
> > struct access" as 634a4408c061 in the Fixes tag and was merged into net
> > yesterday heading for 7.1-rc5. The latter still refers to it as
> > 041e88fb0c08. Both are now in next-20260519 but only the latter was in
> > next-20260518 which was the latest at the time of Thorsten's message.
> >
> > Greg, this means picking e3ac0d9f1a20 instead of 162b1adeb057 should result
> > in a valid Fixes tag.
>
> Ok, now done.  Be careful of duplicate commits in different branches
> that are marked for backporting with different ids.  It can cause
> massive confusion (i.e. don't be like the drm tree...)

Noted. I guess I need to dig into how other trees do to avoid that.
The problem seem related to using 2 trees: bluetooth->net (fixes only,
rebased on each RC) versus bluetooth-next->net-next (development,
rebased once per release).

> thanks,
>
> greg k-h



-- 
Luiz Augusto von Dentz

Re: [GIT PULL] bluetooth 2026-05-14

[Greg KH]

On Wed, May 20, 2026 at 09:11:42AM -0400, Luiz Augusto von Dentz wrote:
> Hi Greg,
> 
> On Wed, May 20, 2026 at 8:47 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, May 19, 2026 at 07:37:35PM +0200, August Wikerfors wrote:
> > > On 2026-05-19 17:49, Luiz Augusto von Dentz wrote:
> > > > Hi Greg,
> > > >
> > > > On Tue, May 19, 2026 at 11:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
> > > > > > Hi Greg,
> > > > > >
> > > > > > On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > > > > > > > On 5/19/26 12:30, Greg KH wrote:
> > > > > > > > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > > > > > > > > > On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > > > > > > > > > > On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > > > > > > > > > >
> > > > > > > > > > > > The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > > > > > > > > > > >    net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > > > > > > > > > > >
> > > > > > > > > > > > are available in the Git repository at:
> > > > > > > > > > > >
> > > > > > > > > > > >    git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > > > > > > > > > > >
> > > > > > > > > > > > for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > > > > > > > > > > >
> > > > > > > > > > > >    Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > > > > > > > > > >
> > > > > > > > > > > It seems this PR sadly came too late for this week's net PR to mainline
> > > > > > > > > > > that was merged yesterday.
> > > > > > > > > > >
> > > > > > > > > > > TWIMC, from my point of view, it would be great if we somehow could
> > > > > > > > > > > still get the changes from this PR or at least the btmtk fix it
> > > > > > > > > > > contains[1] to mainline this week before -rc4, as it is fixing a
> > > > > > > > > > > regression known since 2026-04-24 that at least five people encountered
> > > > > > > > > > > with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > > > > > > > > > > validate WMT event SKB length before struct access") [006b9943b982 in
> > > > > > > > > > > -next].
> > > > > > > > > >
> > > > > > > > > > Greg, Sasha, that [1] fix I was talking about now reached -next as
> > > > > > > > > > 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > > > > > > > > > events") and will likely hit mainline on Thursday or so with the weekly
> > > > > > > > > > -net PR to -mainline. If that's good enough for you, I'd say it would be
> > > > > > > > > > good to pick this up for the next round of stable kernels.
> > > > > > > > >
> > > > > > > > > That "Fixes:" tag is referring to something that is also not in any
> > > > > > > > > tree, but that commit does have a cc: stable in it.  So do we need both
> > > > > > > > > of these:
> > > > > > > >
> > > > > > > > Valid question, as yes, there is a slight mixup here:
> > > > > > > >
> > > > > > > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> > > > > > > >
> > > > > > > > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > > > > > > > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > > > > > > > btmtk: validate WMT event SKB length before struct access") -- the one
> > > > > > > > that is causing the regression that I want to get fixed. So we now only
> > > > > > > > need:
> > > > > > > >
> > > > > > > > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
> > > > > > >
> > > > > > > Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> > > > > > > nightmare to track over time, ugh.
> > > > > >
> > > > > > Hmm, did we get the wrong hash or something? Usually, that would show
> > > > > > up in the verify-fixes.sh, but perhaps it didn't capture it this time
> > > > > > for some reason, perhaps I'm running an outdated version or something
> > > > > > similar.
> > > > >
> > > > > Something went wrong if we ended up with a patch in the stable trees,
> > > > > yet this fix is referring to it as a different git sha.  Don't know
> > > > > where the disconnect happend :(
> > > >
> > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before
> > > > struct access")
> > > >
> > > > I don't have that in any of our tree either, this is actually
> > > > 634a4408c061 on all trees in the chain:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=634a4408c061
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=634a4408c061
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=634a4408c061
> > > >
> > > > Or actually that was the hash before it got rebased on bluetooth-next tree:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=041e88fb0c08
> > > >
> > > > But I didn't send the PR from that three so perhaps somebody else sent
> > > > it to stable with the wrong fixes tag?
> > > I believe the confusion comes from "Bluetooth: btmtk: accept too short WMT
> > > FUNC_CTRL events" itself currently having different commit hashes in
> > > bluetooth (e3ac0d9f1a20) and bluetooth-next (162b1adeb057). The former
> > > correctly refers to "Bluetooth: btmtk: validate WMT event SKB length before
> > > struct access" as 634a4408c061 in the Fixes tag and was merged into net
> > > yesterday heading for 7.1-rc5. The latter still refers to it as
> > > 041e88fb0c08. Both are now in next-20260519 but only the latter was in
> > > next-20260518 which was the latest at the time of Thorsten's message.
> > >
> > > Greg, this means picking e3ac0d9f1a20 instead of 162b1adeb057 should result
> > > in a valid Fixes tag.
> >
> > Ok, now done.  Be careful of duplicate commits in different branches
> > that are marked for backporting with different ids.  It can cause
> > massive confusion (i.e. don't be like the drm tree...)
> 
> Noted. I guess I need to dig into how other trees do to avoid that.
> The problem seem related to using 2 trees: bluetooth->net (fixes only,
> rebased on each RC) versus bluetooth-next->net-next (development,
> rebased once per release).

Just never rebase any public tree please.

Re: [GIT PULL] bluetooth 2026-05-14

[Luiz Augusto von Dentz]

Hi Greg,

On Wed, May 20, 2026 at 9:14 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, May 20, 2026 at 09:11:42AM -0400, Luiz Augusto von Dentz wrote:
> > Hi Greg,
> >
> > On Wed, May 20, 2026 at 8:47 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, May 19, 2026 at 07:37:35PM +0200, August Wikerfors wrote:
> > > > On 2026-05-19 17:49, Luiz Augusto von Dentz wrote:
> > > > > Hi Greg,
> > > > >
> > > > > On Tue, May 19, 2026 at 11:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
> > > > > > > Hi Greg,
> > > > > > >
> > > > > > > On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > > >
> > > > > > > > On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
> > > > > > > > > On 5/19/26 12:30, Greg KH wrote:
> > > > > > > > > > On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
> > > > > > > > > > > On 5/15/26 17:10, Thorsten Leemhuis wrote:
> > > > > > > > > > > > On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
> > > > > > > > > > > > >    net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
> > > > > > > > > > > > >
> > > > > > > > > > > > > are available in the Git repository at:
> > > > > > > > > > > > >
> > > > > > > > > > > > >    git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
> > > > > > > > > > > > >
> > > > > > > > > > > > > for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
> > > > > > > > > > > > >
> > > > > > > > > > > > >    Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
> > > > > > > > > > > >
> > > > > > > > > > > > It seems this PR sadly came too late for this week's net PR to mainline
> > > > > > > > > > > > that was merged yesterday.
> > > > > > > > > > > >
> > > > > > > > > > > > TWIMC, from my point of view, it would be great if we somehow could
> > > > > > > > > > > > still get the changes from this PR or at least the btmtk fix it
> > > > > > > > > > > > contains[1] to mainline this week before -rc4, as it is fixing a
> > > > > > > > > > > > regression known since 2026-04-24 that at least five people encountered
> > > > > > > > > > > > with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
> > > > > > > > > > > > validate WMT event SKB length before struct access") [006b9943b982 in
> > > > > > > > > > > > -next].
> > > > > > > > > > >
> > > > > > > > > > > Greg, Sasha, that [1] fix I was talking about now reached -next as
> > > > > > > > > > > 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
> > > > > > > > > > > events") and will likely hit mainline on Thursday or so with the weekly
> > > > > > > > > > > -net PR to -mainline. If that's good enough for you, I'd say it would be
> > > > > > > > > > > good to pick this up for the next round of stable kernels.
> > > > > > > > > >
> > > > > > > > > > That "Fixes:" tag is referring to something that is also not in any
> > > > > > > > > > tree, but that commit does have a cc: stable in it.  So do we need both
> > > > > > > > > > of these:
> > > > > > > > >
> > > > > > > > > Valid question, as yes, there is a slight mixup here:
> > > > > > > > >
> > > > > > > > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
> > > > > > > > >
> > > > > > > > > That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
> > > > > > > > > -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
> > > > > > > > > btmtk: validate WMT event SKB length before struct access") -- the one
> > > > > > > > > that is causing the regression that I want to get fixed. So we now only
> > > > > > > > > need:
> > > > > > > > >
> > > > > > > > > > 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
> > > > > > > >
> > > > > > > > Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
> > > > > > > > nightmare to track over time, ugh.
> > > > > > >
> > > > > > > Hmm, did we get the wrong hash or something? Usually, that would show
> > > > > > > up in the verify-fixes.sh, but perhaps it didn't capture it this time
> > > > > > > for some reason, perhaps I'm running an outdated version or something
> > > > > > > similar.
> > > > > >
> > > > > > Something went wrong if we ended up with a patch in the stable trees,
> > > > > > yet this fix is referring to it as a different git sha.  Don't know
> > > > > > where the disconnect happend :(
> > > > >
> > > > > 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before
> > > > > struct access")
> > > > >
> > > > > I don't have that in any of our tree either, this is actually
> > > > > 634a4408c061 on all trees in the chain:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=634a4408c061
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=634a4408c061
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=634a4408c061
> > > > >
> > > > > Or actually that was the hash before it got rebased on bluetooth-next tree:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=041e88fb0c08
> > > > >
> > > > > But I didn't send the PR from that three so perhaps somebody else sent
> > > > > it to stable with the wrong fixes tag?
> > > > I believe the confusion comes from "Bluetooth: btmtk: accept too short WMT
> > > > FUNC_CTRL events" itself currently having different commit hashes in
> > > > bluetooth (e3ac0d9f1a20) and bluetooth-next (162b1adeb057). The former
> > > > correctly refers to "Bluetooth: btmtk: validate WMT event SKB length before
> > > > struct access" as 634a4408c061 in the Fixes tag and was merged into net
> > > > yesterday heading for 7.1-rc5. The latter still refers to it as
> > > > 041e88fb0c08. Both are now in next-20260519 but only the latter was in
> > > > next-20260518 which was the latest at the time of Thorsten's message.
> > > >
> > > > Greg, this means picking e3ac0d9f1a20 instead of 162b1adeb057 should result
> > > > in a valid Fixes tag.
> > >
> > > Ok, now done.  Be careful of duplicate commits in different branches
> > > that are marked for backporting with different ids.  It can cause
> > > massive confusion (i.e. don't be like the drm tree...)
> >
> > Noted. I guess I need to dig into how other trees do to avoid that.
> > The problem seem related to using 2 trees: bluetooth->net (fixes only,
> > rebased on each RC) versus bluetooth-next->net-next (development,
> > rebased once per release).
>
> Just never rebase any public tree please.

I guess the alternative is to do merges, right? While I understand
this will not be changing the sha-ids I don't think it changes the
fact that fixes applied on the bluetooth-next cannot be merged into
bluetooth. Is there a way to retain the IDs across trees? The
alternative, I guess, would be to apply fixes to bluetooth tree and
then merge them back to bluetooth-next to preserve the IDs. This would
make the CI job slightly harder, as it would need to detect if a Fixes
tag exists; if so, it would probably need to go through the Bluetooth
tree first.

-- 
Luiz Augusto von Dentz