[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.
