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

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

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

[Linus Torvalds]

On Wed, 20 May 2026 at 08:53, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> >
> > Just never rebase any public tree please.
>
> I guess the alternative is to do merges, right?

No. Back-merges are bad too, unless they have a really damn solid
reason for them, and some "keep up with other peoples work" is not
that.

The primary model should be that you care about your own work, and
make sure that that is as stable as possible. Do *NOT* try to chase
other people's work. Not with merges, not with rebases.

Then when your branch is all done and ready, you ask upstream (in your
case typically the networking tree) to pull it.

Some people at that point *jump* to the point where upstream merged from them.

Or another fairly common model is to have just started another branch
for future work. Keeping independent development branches for
different features is also a good thing to strive for, because it
makes it easier for different people to work on different branches
without messing with each other, but it also means that one feature
being delayed (due to unexpected problems or whatever) doesn't affect
other branches. And if done well, it also means that you wouldn't even
care about the whole "point where upstream merged", because your other
work simply isn't dependent on things like that.

So there are many ways to deal with them, but rebasing and merging are
typically the worst ones that should be avoided unless active problems
happen.

Sometimes you have to rebase because of a mistake. Sometimes you need
to do back-merges. But you should damn well have *reasons* for both
that aren't "that's just how we work".

Back-merges in particular need to not just be "merge upstream". They
need a commit message that explains *why* you're merging upstream (and
not merge some random point, the same way you shouldn't start
development at some random point of questionable stability).

Rebasing is "invisible" except for the mess it leaves with random
commit ids (and the problems it can cause for anybody who happened to
use an older version). So you can't explain it, but it should then be
explained to upstream why you ask them to pull recent changes that
clearly cannot have been tested in that form.

                Linus

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

[Thorsten Leemhuis]

On 5/20/26 21:32, Linus Torvalds wrote:
> On Wed, 20 May 2026 at 08:53, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>>> Just never rebase any public tree please.
>> I guess the alternative is to do merges, right?
> No. Back-merges are bad too, unless they have a really damn solid
> reason for them, and some "keep up with other peoples work" is not
> that.
> 
> The primary model should be that you care about your own work, and
> make sure that that is as stable as possible. Do *NOT* try to chase
> other people's work. Not with merges, not with rebases. [...]
> [...]
> Sometimes you have to rebase because of a mistake. Sometimes you need
> to do back-merges. But you should damn well have *reasons* for both
> that aren't "that's just how we work".

Speaking of mistakes, one happens occasionally that you afaics did not
cover here. And it's one where I'd be interested in your opinion (and
maybe Greg's from the stable perspective, too):

How to deal with cases where one fix was merged to a public -next branch
for merging in the next cycle (and thus was mixed up with many
non-fixes) but then turns out should be mainlined this cycle?

I notice such situations a few times per month. I just had exactly that
case for a patch fixing a 7.0 regression. And the answer I got was round
about "sorry, the fix is already in our -next tree, we thus can't merge
it this cycle"[1]. And that seemed wrong to me, which is why I argued
for cherry-picking in that case, but it seems I was not convincing.

And yes, I understand that cherry-picking causes pain (especially for
the stable team) and thus is best avoided -- but mistakes like that will
always happen, so it might be best to know what to do in that case.

> [...]

Ciao, Thorsten

[1] it's for a regression introduced in the 7.0 cycle:
https://lore.kernel.org/all/29a93dc3d9d24b3a809310694ffc5d34@realtek.com/
-- the tree in question afaics is not even in -next, as I can't see the
fix there