Hi, this is your Linux kernel regression tracker again. Top-posting for once, to make this easily accessible for everyone. I sent below inquiry on Saturday and didn't get a reply; and I didn't notice any other activity to get this regression fix mainlined soon. Bluetooth maintainers, what's up here? I'd like to avoid getting Linus involved, but I guess I'm out of options if this mail doesn't get things rolling -- or alternatively an answer why this fix might better wait for the next merge window to get merged. Ciao, Thorsten On 19.02.22 10:18, Thorsten Leemhuis wrote: > > [CCing Johan, Jakub and Dave] > > Hi Bluetooth maintainers! > > On 16.02.22 11:26, Marcel Holtmann wrote: >> >>> Since bt_skb_sendmmsg can be used with the likes of SOCK_STREAM it >>> shall return the partial chunks it could allocate instead of freeing >>> everything as otherwise it can cause problems like bellow. >>> >>> Link: https://lore.kernel.org/linux-bluetooth/aa3ee7ac-6c52-3861-1798-3cc1a37f6ebf@xxxxxxxxxxxxx/T/#m1f9673e4ab0d55a7dccf87905337ab2e67d689f1 >>> Fixes: 81be03e026dc ("Bluetooth: RFCOMM: Replace use of memcpy_from_msg with bt_skb_sendmmsg") >>> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> >>> --- >>> include/net/bluetooth/bluetooth.h | 3 +-- >>> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> patch has been applied to bluetooth-next tree. > > Luiz, Marcel, thx for fixing this 5.16 regression and picking the patch > up for merging. But I have to wonder: why was this simple fix put into a > tree that apparently is meant to only get merged to mainline during the > the next merge window? That will mean this regression will bother people > (maybe Paul is not the only one that is affected by this) for weeks to > come and even make it into 5.17, before it gets fixed for 5.18-rc1. > Despite the lack of a "Cc: <stable@xxxxxxxxxxxxxxx>" tag it likely will > get backporting to 5.17.y and 5.16.y afterwards, but the latter soon > after will be EOLed anyway. > > Correct me if I'm wrong, but that afaik is not how the Linux development > process is meant to handle such regressions. This approach also > contributes to the huge stable and longterm releases after the end of > each merge window, which some people see as a problem. > > I bring this up because there were other regression fixes in the last > few weeks that took such a slow path towards mainline. I also checked > MAINTAINERS and noticed you even have a tree that could feed fixes like > this to Linus via the regular net tree, but apparently you haven't used > it in quite a while: > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git > I rechecked and noticed not a single bluetooth fix was merged between > v5.16-rc1..v5.16. I doubt Jakub or Dave are the reason, as they merge > fixes from downstream trees every week and send them to Linus shortly > after that. > > So why are things like that? Or is there something wrong with my look on > things? > > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) > > P.S.: As the Linux kernel's regression tracker I'm getting a lot of > reports on my table. I can only look briefly into most of them and lack > knowledge about most of the areas they concern. I thus unfortunately > will sometimes get things wrong or miss something important. I hope > that's not the case here; if you think it is, don't hesitate to tell me > in a public reply, it's in everyone's interest to set the public record > straight.
