bluetooth regression fix likely to miss -rc5 (was: Re: [GIT PULL] bluetooth 2026-03-19)

On 3/20/26 01:00, patchwork-bot+netdevbpf@kernel.org wrote:

This pull request was applied to netdev/net.git (main)
by Jakub Kicinski [off-list ref]:

On Thu, 19 Mar 2026 15:04:55 -0400 you wrote:

quoted

The following changes since commit 7ab4a7c5d969642782b8a5b608da0dd02aa9f229:

  MPTCP: fix lock class name family in pm_nl_create_listen_socket (2026-03-19 09:37:48 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-03-19

[...]

Here is the summary with links:
  - [GIT,PULL] bluetooth 2026-03-19
    https://git.kernel.org/netdev/net/c/57ce3b2e9cda

[preface: sorry for being a pest again and making life of maintainers
harder with mails like this; but I think Linus (CCed) wants me to bring
up situations like this; Linus, if I'm wrong, please do not hesitate to
tell me]

The quoted bluetooth pull to net afaics came a tiny bit too late for
this week's net PR to mainline. I assume there won't be another this
week, as that would be unusual from a look at the history (and well, if
I'm wrong I'm happy!). That is kind of unfortunate, as those bluetooth
changes contained a fix[1] for a regression that at least three people
reported (and I know of at least one other person that was affected)[2].
A regression that is known for nearly a month now and thus already took
way longer than the "fix within a week, preferably before the next rc."
rule of thumb Linus recently mentioned[3].

We had a similar situation last week already with the netfilter PR to
net[4], which came on a Friday -- and missed last week's net PR to
mainline, so those netfilter changes were only mainlined yesterday. Due
to this a revert[5] that fixes a regression multiple people reported[6]
missed -rc4 and will only be in -rc5.

These two examples make me wonder if we might want to optimize something
here. Have a second net PR to mainline in some weeks? Or should the net
PR to mainline maybe be sent later during the week whenever possible
(say on a Friday)? That would have avoided the problem. And yes, I know,
Linus at some point due to last-minute problems asked to send net
mainline PRs mid-week. But he iirc (not totally sure, hence correct me
if I'm wrong) recently mentioned that things have improved. That's why
I'm wondering if we should forget about the mid-week thing again and
shift things a little.

Ciao, Thorsten

P.S. Once again I wonder if we should have a dedicated tree to collect
and quickly mainline regression fixes subsystem maintainers ACKed -- but
at the same time I think strongly that it's a totally stupid idea, as
bypassing subsystem has many downsides (like bypassing subsystem
specific CIs, the need for backmerges [or duplicated commits] and things
like that).

[1]
https://lore.kernel.org/all/20260319152247.13225-1-luiz.dentz@gmail.com/ (local)
-- in next as 761fb8ec8778f0
[2]
https://lore.kernel.org/all/20260301233619.1807980-1-joanbrugueram@gmail.com/ (local)
and links to bugzilla in that thread
[3]
https://lore.kernel.org/all/CAHk-%3Dwi86AosXs66-yi54%2BmpQjPu0upxB8ZAfG%2BLsMyJmcuMSA@mail.gmail.com/ (local)
[4] https://lore.kernel.org/all/20260313150614.21177-1-fw@strlen.de/ (local)
[5] https://lore.kernel.org/all/20260313150614.21177-5-fw@strlen.de/ (local)
[6] https://bugzilla.kernel.org/show_bug.cgi?id=221152,
https://bugzilla.kernel.org/show_bug.cgi?id=221158 , and
https://lore.kernel.org/all/143e1a402ad78dd7076516a6ceb637f378310b16.camel@sapience.com/ (local)
(some of those are with stable kernels, where the culprit was backported
and reverted earlier already due to the regression)