| Message ID | 20241016204258.821965-1-luiz.dentz@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | pull request: bluetooth 2024-10-16 | expand |
[CCing Linus, the two other -net maintainers, and the regressions lists] On 16.10.24 22:42, Luiz Augusto von Dentz wrote: > The following changes since commit 11d06f0aaef89f4cad68b92510bd9decff2d7b87: > > net: dsa: vsc73xx: fix reception from VLAN-unaware bridges (2024-10-15 18:41:52 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2024-10-16 FWIW, from my point of view it would be nice if these changes could make it to mainline this week. I know, they missed the weekly -net merge, despite the quoted PR being sent on Wednesday (I assume it was too late in the day). But the set contains a fix for a regression ("Bluetooth: btusb: Fix not being able to reconnect after suspend") that to my knowledge was reported and bisected at least *five* times already since -rc1 (and the culprit recently hit 6.11.4 as well, so more people are likely now affected by this :-/ ). Having "Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001" -mainlined rather sooner that later would be nice, too, as it due to recent backports affects afaics all stable series and iirc was reported at least two times already (and who knows how many people are affected by those bugs that never sat down to report them...). Side note: I recently learned from one of Linus public mails (I can't find right now on lore, sorry) why the -net subsystem is usually merging mid-week. TBH from a regression point of view I have to say I don't like it much, as bad timing with sub-subsystem PRs leads to situation like the one described above. It is not the first time I notice one, but most of the time I did not consider to write a mail about it. Sure, telling sub-subsystems to send their PR earlier to the -net maintainers could help, but even then we loose at least one or two days (e.g. Wed and Thu) every week to get regression fixes mainlined before the next -rc. Ciao, Thorsten > for you to fetch changes up to 2c1dda2acc4192d826e84008d963b528e24d12bc: > > Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 (2024-10-16 16:10:25 -0400) > > ---------------------------------------------------------------- > bluetooth pull request for net: > > - ISO: Fix multiple init when debugfs is disabled > - Call iso_exit() on module unload > - Remove debugfs directory on module init failure > - btusb: Fix not being able to reconnect after suspend > - btusb: Fix regression with fake CSR controllers 0a12:0001 > - bnep: fix wild-memory-access in proto_unregister > > ---------------------------------------------------------------- > Aaron Thompson (3): > Bluetooth: ISO: Fix multiple init when debugfs is disabled > Bluetooth: Call iso_exit() on module unload > Bluetooth: Remove debugfs directory on module init failure > > Luiz Augusto von Dentz (2): > Bluetooth: btusb: Fix not being able to reconnect after suspend > Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 > > Ye Bin (1): > Bluetooth: bnep: fix wild-memory-access in proto_unregister > > drivers/bluetooth/btusb.c | 27 +++++++++------------------ > net/bluetooth/af_bluetooth.c | 3 +++ > net/bluetooth/bnep/core.c | 3 +-- > net/bluetooth/iso.c | 6 +----- > 4 files changed, 14 insertions(+), 25 deletions(-)
Hi Thorsten, On Fri, Oct 18, 2024 at 1:30 AM Thorsten Leemhuis <regressions@leemhuis.info> wrote: > > [CCing Linus, the two other -net maintainers, and the regressions lists] > > On 16.10.24 22:42, Luiz Augusto von Dentz wrote: > > The following changes since commit 11d06f0aaef89f4cad68b92510bd9decff2d7b87: > > > > net: dsa: vsc73xx: fix reception from VLAN-unaware bridges (2024-10-15 18:41:52 -0700) > > > > are available in the Git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2024-10-16 > > FWIW, from my point of view it would be nice if these changes could make > it to mainline this week. I know, they missed the weekly -net merge, > despite the quoted PR being sent on Wednesday (I assume it was too late > in the day). But the set contains a fix for a regression ("Bluetooth: > btusb: Fix not being able to reconnect after suspend") that to my > knowledge was reported and bisected at least *five* times already since > -rc1 (and the culprit recently hit 6.11.4 as well, so more people are > likely now affected by this :-/ ). Having "Bluetooth: btusb: Fix > regression with fake CSR controllers 0a12:0001" -mainlined rather sooner > that later would be nice, too, as it due to recent backports affects > afaics all stable series and iirc was reported at least two times > already (and who knows how many people are affected by those bugs that > never sat down to report them...). +1 I really would like to send the PR sooner but being on the path of hurricane milton made things more complicated, anyway I think the most important ones are the regression fixes: Bluetooth: btusb: Fix not being able to reconnect after suspend Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 > Side note: I recently learned from one of Linus public mails (I can't > find right now on lore, sorry) why the -net subsystem is usually merging > mid-week. TBH from a regression point of view I have to say I don't like > it much, as bad timing with sub-subsystem PRs leads to situation like > the one described above. It is not the first time I notice one, but most > of the time I did not consider to write a mail about it. > > Sure, telling sub-subsystems to send their PR earlier to the -net > maintainers could help, but even then we loose at least one or two days > (e.g. Wed and Thu) every week to get regression fixes mainlined before > the next -rc. Yeah, that said I'm planning to switch to submit fixes more regularly (e.g weekly), which appears to be the cadence of the net tree, that way we narrow the window for landing fixes into linus tree. > Ciao, Thorsten > > > for you to fetch changes up to 2c1dda2acc4192d826e84008d963b528e24d12bc: > > > > Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 (2024-10-16 16:10:25 -0400) > > > > ---------------------------------------------------------------- > > bluetooth pull request for net: > > > > - ISO: Fix multiple init when debugfs is disabled > > - Call iso_exit() on module unload > > - Remove debugfs directory on module init failure > > - btusb: Fix not being able to reconnect after suspend > > - btusb: Fix regression with fake CSR controllers 0a12:0001 > > - bnep: fix wild-memory-access in proto_unregister > > > > ---------------------------------------------------------------- > > Aaron Thompson (3): > > Bluetooth: ISO: Fix multiple init when debugfs is disabled > > Bluetooth: Call iso_exit() on module unload > > Bluetooth: Remove debugfs directory on module init failure > > > > Luiz Augusto von Dentz (2): > > Bluetooth: btusb: Fix not being able to reconnect after suspend > > Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 > > > > Ye Bin (1): > > Bluetooth: bnep: fix wild-memory-access in proto_unregister > > > > drivers/bluetooth/btusb.c | 27 +++++++++------------------ > > net/bluetooth/af_bluetooth.c | 3 +++ > > net/bluetooth/bnep/core.c | 3 +-- > > net/bluetooth/iso.c | 6 +----- > > 4 files changed, 14 insertions(+), 25 deletions(-) >
On 18.10.24 18:45, Luiz Augusto von Dentz wrote: > On Fri, Oct 18, 2024 at 1:30 AM Thorsten Leemhuis > <regressions@leemhuis.info> wrote: >> On 16.10.24 22:42, Luiz Augusto von Dentz wrote: >>> The following changes since commit 11d06f0aaef89f4cad68b92510bd9decff2d7b87: >>> >>> net: dsa: vsc73xx: fix reception from VLAN-unaware bridges (2024-10-15 18:41:52 -0700) >>> >>> are available in the Git repository at: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2024-10-16 >> >> FWIW, from my point of view it would be nice if these changes could make >> it to mainline this week. I know, they missed the weekly -net merge, >> despite the quoted PR being sent on Wednesday (I assume it was too late >> in the day). But the set contains a fix for a regression ("Bluetooth: >> btusb: Fix not being able to reconnect after suspend") that to my >> knowledge was reported and bisected at least *five* times already since >> -rc1 (and the culprit recently hit 6.11.4 as well, so more people are >> likely now affected by this :-/ ). Meanwhile two more reports came it for this issue. And I became aware of two more for the other Luiz mentioned. I noticed my chance that Fedora became impatient and picked up both fixes. >> Having "Bluetooth: btusb: Fix >> regression with fake CSR controllers 0a12:0001" -mainlined rather sooner >> that later would be nice, too, as it due to recent backports affects >> afaics all stable series and iirc was reported at least two times >> already (and who knows how many people are affected by those bugs that >> never sat down to report them...). > > +1 > > I really would like to send the PR sooner but being on the path of > hurricane milton made things more complicated, anyway I think the most > important ones are the regression fixes: Linus, FWIW, in case you just those: > Bluetooth: btusb: Fix not being able to reconnect after suspend That one is a2ce7481010a32 ("Bluetooth: btusb: Fix not being able to reconnect after suspend") in -next and 4084286151fc91 in the PR above. It was posted as https://lore.kernel.org/all/20241014202326.381559-1-luiz.dentz@gmail.com/, but Luiz at least fixed the Fixes: tag before committing the fix. > Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 That one is b29d4ac729754f ("Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001") in -next and 2c1dda2acc4192 in the PR above. It was posted here: https://lore.kernel.org/all/20241016154700.682621-1-luiz.dentz@gmail.com/ (not sure if there were any modifications afterwards). Ciao, Thorsten >> Side note: I recently learned from one of Linus public mails (I can't >> find right now on lore, sorry) why the -net subsystem is usually merging >> mid-week. TBH from a regression point of view I have to say I don't like >> it much, as bad timing with sub-subsystem PRs leads to situation like >> the one described above. It is not the first time I notice one, but most >> of the time I did not consider to write a mail about it. >> >> Sure, telling sub-subsystems to send their PR earlier to the -net >> maintainers could help, but even then we loose at least one or two days >> (e.g. Wed and Thu) every week to get regression fixes mainlined before >> the next -rc. > > Yeah, that said I'm planning to switch to submit fixes more regularly > (e.g weekly), which appears to be the cadence of the net tree, that > way we narrow the window for landing fixes into linus tree. > >> Ciao, Thorsten >> >>> for you to fetch changes up to 2c1dda2acc4192d826e84008d963b528e24d12bc: >>> >>> Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 (2024-10-16 16:10:25 -0400) >>> >>> ---------------------------------------------------------------- >>> bluetooth pull request for net: >>> >>> - ISO: Fix multiple init when debugfs is disabled >>> - Call iso_exit() on module unload >>> - Remove debugfs directory on module init failure >>> - btusb: Fix not being able to reconnect after suspend >>> - btusb: Fix regression with fake CSR controllers 0a12:0001 >>> - bnep: fix wild-memory-access in proto_unregister >>> >>> ---------------------------------------------------------------- >>> Aaron Thompson (3): >>> Bluetooth: ISO: Fix multiple init when debugfs is disabled >>> Bluetooth: Call iso_exit() on module unload >>> Bluetooth: Remove debugfs directory on module init failure >>> >>> Luiz Augusto von Dentz (2): >>> Bluetooth: btusb: Fix not being able to reconnect after suspend >>> Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 >>> >>> Ye Bin (1): >>> Bluetooth: bnep: fix wild-memory-access in proto_unregister >>> >>> drivers/bluetooth/btusb.c | 27 +++++++++------------------ >>> net/bluetooth/af_bluetooth.c | 3 +++ >>> net/bluetooth/bnep/core.c | 3 +-- >>> net/bluetooth/iso.c | 6 +----- >>> 4 files changed, 14 insertions(+), 25 deletions(-) >> > >
On Fri, 18 Oct 2024 at 09:45, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > I really would like to send the PR sooner but being on the path of > hurricane milton made things more complicated, anyway I think the most > important ones are the regression fixes: > > Bluetooth: btusb: Fix not being able to reconnect after suspend > Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 I cherry-picked just those, but then I ended up looking at the rest just to see if duplicating the commits was worth it. And that just made me go "nope", and I undid my cherry-picks and instead just pulled the whole thing. The rest of the fixes looked too trivial to be worth me having created a separate cherry-picked "just the most critical regression fixes" bt-fixes branch. IOW: I've pulled the bluetooth fixes branch directly, but sincerely hope this won't become a pattern. Linus
Hello: This pull request was applied to bpf/bpf.git (master) by Linus Torvalds <torvalds@linux-foundation.org>: On Wed, 16 Oct 2024 16:42:58 -0400 you wrote: > The following changes since commit 11d06f0aaef89f4cad68b92510bd9decff2d7b87: > > net: dsa: vsc73xx: fix reception from VLAN-unaware bridges (2024-10-15 18:41:52 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2024-10-16 > > [...] Here is the summary with links: - pull request: bluetooth 2024-10-16 https://git.kernel.org/bpf/bpf/c/d7f513ae7b10 You are awesome, thank you!
On 20.10.24 23:25, Linus Torvalds wrote: > On Fri, 18 Oct 2024 at 09:45, Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: >> >> I really would like to send the PR sooner but being on the path of >> hurricane milton made things more complicated, anyway I think the most >> important ones are the regression fixes: >> >> Bluetooth: btusb: Fix not being able to reconnect after suspend >> Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 BTW, Luiz, thanks for backing up my request, especially given the Milton aspect! > I cherry-picked just those, but then I ended up looking at the rest > just to see if duplicating the commits was worth it. > > And that just made me go "nope", and I undid my cherry-picks and > instead just pulled the whole thing. Thx! > IOW: I've pulled the bluetooth fixes branch directly, but sincerely > hope this won't become a pattern. Just to clarify: I assume it's the "taking things directly and thus bypassing -net" that is the problem here? So if the -net maintainers would have pulled this on say Friday[1] and sent a second PR that week it in a case like this would have been totally fine? Ciao, Thorsten
On 10/18/24 07:30, Thorsten Leemhuis wrote: > [CCing Linus, the two other -net maintainers, and the regressions lists] > > On 16.10.24 22:42, Luiz Augusto von Dentz wrote: >> The following changes since commit 11d06f0aaef89f4cad68b92510bd9decff2d7b87: >> >> net: dsa: vsc73xx: fix reception from VLAN-unaware bridges (2024-10-15 18:41:52 -0700) >> >> are available in the Git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2024-10-16 > > FWIW, from my point of view it would be nice if these changes could make > it to mainline this week. I know, they missed the weekly -net merge, > despite the quoted PR being sent on Wednesday (I assume it was too late > in the day). The net PR is prepared and sent on Thursday morning - either European Time or West Cost, depending on who actually is cooking it. Wednesday is usually/nearly always a good time for PR to be send on netdev to land into the next 'net' PR, but due to some unfortunate scheduling, we are lagging behind the netdev ML traffic - to the point that I'm processing this email only now. The limited capacity will last for all the current week, but we should come back to speed from the next one. Cheers, Paolo
Hi Paolo, On Mon, Oct 21, 2024 at 11:29 AM Paolo Abeni <pabeni@redhat.com> wrote: > > On 10/18/24 07:30, Thorsten Leemhuis wrote: > > [CCing Linus, the two other -net maintainers, and the regressions lists] > > > > On 16.10.24 22:42, Luiz Augusto von Dentz wrote: > >> The following changes since commit 11d06f0aaef89f4cad68b92510bd9decff2d7b87: > >> > >> net: dsa: vsc73xx: fix reception from VLAN-unaware bridges (2024-10-15 18:41:52 -0700) > >> > >> are available in the Git repository at: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2024-10-16 > > > > FWIW, from my point of view it would be nice if these changes could make > > it to mainline this week. I know, they missed the weekly -net merge, > > despite the quoted PR being sent on Wednesday (I assume it was too late > > in the day). > > The net PR is prepared and sent on Thursday morning - either European > Time or West Cost, depending on who actually is cooking it. > > Wednesday is usually/nearly always a good time for PR to be send on > netdev to land into the next 'net' PR, but due to some unfortunate > scheduling, we are lagging behind the netdev ML traffic - to the point > that I'm processing this email only now. > > The limited capacity will last for all the current week, but we should > come back to speed from the next one. Thanks for the feedback, I will try to get the bluetooth tree PR done on Wednesday (weekly) morning (East Coast) then. > > Cheers, > > Paolo >
On Mon, 21 Oct 2024 at 01:22, Thorsten Leemhuis <regressions@leemhuis.info> wrote: > > Just to clarify: I assume it's the "taking things directly and thus > bypassing -net" that is the problem here? Well, it's not a *problem* per se. It's just not something I want to be a regular occurrence, because then the lines of responsibility get less clear. And we've seen (many times) how that causes a kind of "bystander effect" where everybody kind of just expects somebody else to handle it, and things start falling through the cracks. IOW: having clear lines of "this goes here" just avoids a lot of waffling. So that's actually one of the main things about being a maintainer: sure, there's the whole "enough technical knowledge to be able to handle it", but a *lot* of maintainership is literally just about being responsible (and responsive) for some area, and people _knowing_ you're responsible for that area, so that there is less of the "who should take care of this patch" confusion. That said, in situations like this, where some small part missed a regular subsystem pull request, I don't think it's problematic to just go "let's bypass the subsystem, and get just this thing fixed asap". Not when it happens rarely (like this time), and not when it happens in a way where everybody is aware of it (like this time). So I think in this case it was probably *better* to just pull a very small and targeted fix for bluetooth issues, than have the networking tree send me out-of-sequence pull request that had other things too in addition to a high-priority bluetooth fix. Put another way: having clear lines of maintainership is important, but it's also important to not make things *too* black-and-white. Exceptions are fine, as long as they clearly remain the unusual case and people explain them. (That is basically true of pretty much everything. A lot of the development rules like "don't rebase" are things where the occasional exception with an _explanation_ for why it happened is perfectly fine) Developers are people. Black-and-white rules are for machines. Linus
The following changes since commit 11d06f0aaef89f4cad68b92510bd9decff2d7b87: net: dsa: vsc73xx: fix reception from VLAN-unaware bridges (2024-10-15 18:41:52 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2024-10-16 for you to fetch changes up to 2c1dda2acc4192d826e84008d963b528e24d12bc: Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 (2024-10-16 16:10:25 -0400) ---------------------------------------------------------------- bluetooth pull request for net: - ISO: Fix multiple init when debugfs is disabled - Call iso_exit() on module unload - Remove debugfs directory on module init failure - btusb: Fix not being able to reconnect after suspend - btusb: Fix regression with fake CSR controllers 0a12:0001 - bnep: fix wild-memory-access in proto_unregister ---------------------------------------------------------------- Aaron Thompson (3): Bluetooth: ISO: Fix multiple init when debugfs is disabled Bluetooth: Call iso_exit() on module unload Bluetooth: Remove debugfs directory on module init failure Luiz Augusto von Dentz (2): Bluetooth: btusb: Fix not being able to reconnect after suspend Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 Ye Bin (1): Bluetooth: bnep: fix wild-memory-access in proto_unregister drivers/bluetooth/btusb.c | 27 +++++++++------------------ net/bluetooth/af_bluetooth.c | 3 +++ net/bluetooth/bnep/core.c | 3 +-- net/bluetooth/iso.c | 6 +----- 4 files changed, 14 insertions(+), 25 deletions(-)