Follow-up to "net: drop bad gso csum_start and offset in virtio_net_hdr" - backport for 5.15 needed
Hi,
the issue was so far handled in https://lore.kernel.org/regressions/ZsyMzW-4ee_U8NoX@eldamar.lan/T/#m390d6ef... and https://bugzilla.kernel.org/show_bug.cgi?id=219129
I haven’t seen any communication whether a backport for 5.15 is already in progress, so I thought I’d follow up here.
Today we rolled out 5.15.165 and immediately ran into the same issue. There’s at least one other person asking for a 5.15 backport in Bugzilla.
Hugs, Christian
-- Christian Theune - A97C62CE - 0179 7808366 @theuni - christian@theune.cc
On Tue, Sep 03, 2024 at 09:37:30AM +0200, Christian Theune wrote:
Hi,
the issue was so far handled in https://lore.kernel.org/regressions/ZsyMzW-4ee_U8NoX@eldamar.lan/T/#m390d6ef... and https://bugzilla.kernel.org/show_bug.cgi?id=219129
I haven’t seen any communication whether a backport for 5.15 is already in progress, so I thought I’d follow up here.
Someone needs to send a working set of patches to apply.
thanks,
greg k-h
On Tue, Sep 3, 2024 at 4:03 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Sep 03, 2024 at 09:37:30AM +0200, Christian Theune wrote:
Hi,
the issue was so far handled in https://lore.kernel.org/regressions/ZsyMzW-4ee_U8NoX@eldamar.lan/T/#m390d6ef... and https://bugzilla.kernel.org/show_bug.cgi?id=219129
I haven’t seen any communication whether a backport for 5.15 is already in progress, so I thought I’d follow up here.
Someone needs to send a working set of patches to apply.
The following stack of patches applies cleanly to 5.15.166 (original SHA1s, git log order, so inverse of order to apply):
89add40066f9e net: drop bad gso csum_start and offset in virtio_net_hdr 9840036786d9 gso: fix dodgy bit handling for GSO_UDP_L4 fc8b2a619469 net: more strict VIRTIO_NET_HDR_GSO_UDP_L4 validation
All three are already present in 6.1.109
Please let me know if I should send that stack using git send-email, or whether this is sufficient into to backport.
The third commit has one Fixes referencing them:
1382e3b6a350 net: change maximum number of UDP segments to 128
This simple -2/+2 line patch unfortunately cannot be backported without conflicts without backporting non-stable feature changes. There is a backport to 6.1.y, but that also won't apply cleanly to 5.15.166 without backporting a feature (e2a4392b61f6 "udp: introduce udp->udp_flags"), which itself does not apply cleanly.
So simplest is probably to fix up this commit and send it using git send-email. I can do that as part of the stack with the above 3 patches, or stand-alone if the above can be cherry-picked by SHA1.
Thanks,
Willem
On Mon, Sep 09, 2024 at 12:05:17AM -0400, Willem de Bruijn wrote:
On Tue, Sep 3, 2024 at 4:03 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Sep 03, 2024 at 09:37:30AM +0200, Christian Theune wrote:
Hi,
the issue was so far handled in https://lore.kernel.org/regressions/ZsyMzW-4ee_U8NoX@eldamar.lan/T/#m390d6ef... and https://bugzilla.kernel.org/show_bug.cgi?id=219129
I haven’t seen any communication whether a backport for 5.15 is already in progress, so I thought I’d follow up here.
Someone needs to send a working set of patches to apply.
The following stack of patches applies cleanly to 5.15.166 (original SHA1s, git log order, so inverse of order to apply):
89add40066f9e net: drop bad gso csum_start and offset in virtio_net_hdr 9840036786d9 gso: fix dodgy bit handling for GSO_UDP_L4 fc8b2a619469 net: more strict VIRTIO_NET_HDR_GSO_UDP_L4 validation
All three are already present in 6.1.109
Please let me know if I should send that stack using git send-email, or whether this is sufficient into to backport.
I just tried it, they do not apply cleanly here for me at all :(
The third commit has one Fixes referencing them:
1382e3b6a350 net: change maximum number of UDP segments to 128
This simple -2/+2 line patch unfortunately cannot be backported without conflicts without backporting non-stable feature changes. There is a backport to 6.1.y, but that also won't apply cleanly to 5.15.166 without backporting a feature (e2a4392b61f6 "udp: introduce udp->udp_flags"), which itself does not apply cleanly.
So simplest is probably to fix up this commit and send it using git send-email. I can do that as part of the stack with the above 3 patches, or stand-alone if the above can be cherry-picked by SHA1.
Please send me a set of working, and tested, patches and we will be glad to consider it.
thanks,
greg k-h
Greg KH wrote:
On Mon, Sep 09, 2024 at 12:05:17AM -0400, Willem de Bruijn wrote:
On Tue, Sep 3, 2024 at 4:03 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Sep 03, 2024 at 09:37:30AM +0200, Christian Theune wrote:
Hi,
the issue was so far handled in https://lore.kernel.org/regressions/ZsyMzW-4ee_U8NoX@eldamar.lan/T/#m390d6ef... and https://bugzilla.kernel.org/show_bug.cgi?id=219129
I haven’t seen any communication whether a backport for 5.15 is already in progress, so I thought I’d follow up here.
Someone needs to send a working set of patches to apply.
The following stack of patches applies cleanly to 5.15.166 (original SHA1s, git log order, so inverse of order to apply):
89add40066f9e net: drop bad gso csum_start and offset in virtio_net_hdr 9840036786d9 gso: fix dodgy bit handling for GSO_UDP_L4 fc8b2a619469 net: more strict VIRTIO_NET_HDR_GSO_UDP_L4 validation
All three are already present in 6.1.109
Please let me know if I should send that stack using git send-email, or whether this is sufficient into to backport.
I just tried it, they do not apply cleanly here for me at all :(
The third commit has one Fixes referencing them:
1382e3b6a350 net: change maximum number of UDP segments to 128
This simple -2/+2 line patch unfortunately cannot be backported without conflicts without backporting non-stable feature changes. There is a backport to 6.1.y, but that also won't apply cleanly to 5.15.166 without backporting a feature (e2a4392b61f6 "udp: introduce udp->udp_flags"), which itself does not apply cleanly.
So simplest is probably to fix up this commit and send it using git send-email. I can do that as part of the stack with the above 3 patches, or stand-alone if the above can be cherry-picked by SHA1.
Please send me a set of working, and tested, patches and we will be glad to consider it.
Done:
https://lore.kernel.org/stable/20240909182506.270136-1-willemdebruijn.kernel...
The following worked fine for me. I hope I did not overlook anything. Compile tested only. But as said, the same patches have landed in 6.1-stable.
git fetch linux-stable linux-5.15.y git checkout linux-stable/linux-5.15.y git cherry-pick fc8b2a619469 git cherry-pick 9840036786d9 git cherry-pick 89add40066f9e make defconfig make -j 64
Unfortunately, the key commit itself has a bug report against it. I am working on that right now.
But as the existing patch that it refers to in its Fixes has landed in all stable kernels and is causing reports, it is a backporting case of damned if we do, damned if we don't.
I intend to have a fix ready ASAP for netdev-net/main. If all stable branches have all backports, it should apply cleanly everywhere. Just not ready to be included in this series from the start.
I can contribute live testing and can quickly reproduce the issue.
If anything is there that should be tested for apart from verifying the fix, I’d be happy to try.
Christian
On 9. Sep 2024, at 20:34, Willem de Bruijn willemdebruijn.kernel@gmail.com wrote:
Greg KH wrote:
On Mon, Sep 09, 2024 at 12:05:17AM -0400, Willem de Bruijn wrote:
On Tue, Sep 3, 2024 at 4:03 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Sep 03, 2024 at 09:37:30AM +0200, Christian Theune wrote:
Hi,
the issue was so far handled in https://lore.kernel.org/regressions/ZsyMzW-4ee_U8NoX@eldamar.lan/T/#m390d6ef... and https://bugzilla.kernel.org/show_bug.cgi?id=219129
I haven’t seen any communication whether a backport for 5.15 is already in progress, so I thought I’d follow up here.
Someone needs to send a working set of patches to apply.
The following stack of patches applies cleanly to 5.15.166 (original SHA1s, git log order, so inverse of order to apply):
89add40066f9e net: drop bad gso csum_start and offset in virtio_net_hdr 9840036786d9 gso: fix dodgy bit handling for GSO_UDP_L4 fc8b2a619469 net: more strict VIRTIO_NET_HDR_GSO_UDP_L4 validation
All three are already present in 6.1.109
Please let me know if I should send that stack using git send-email, or whether this is sufficient into to backport.
I just tried it, they do not apply cleanly here for me at all :(
The third commit has one Fixes referencing them:
1382e3b6a350 net: change maximum number of UDP segments to 128
This simple -2/+2 line patch unfortunately cannot be backported without conflicts without backporting non-stable feature changes. There is a backport to 6.1.y, but that also won't apply cleanly to 5.15.166 without backporting a feature (e2a4392b61f6 "udp: introduce udp->udp_flags"), which itself does not apply cleanly.
So simplest is probably to fix up this commit and send it using git send-email. I can do that as part of the stack with the above 3 patches, or stand-alone if the above can be cherry-picked by SHA1.
Please send me a set of working, and tested, patches and we will be glad to consider it.
Done:
https://lore.kernel.org/stable/20240909182506.270136-1-willemdebruijn.kernel...
The following worked fine for me. I hope I did not overlook anything. Compile tested only. But as said, the same patches have landed in 6.1-stable.
git fetch linux-stable linux-5.15.y git checkout linux-stable/linux-5.15.y git cherry-pick fc8b2a619469 git cherry-pick 9840036786d9 git cherry-pick 89add40066f9e make defconfig make -j 64
Unfortunately, the key commit itself has a bug report against it. I am working on that right now.
But as the existing patch that it refers to in its Fixes has landed in all stable kernels and is causing reports, it is a backporting case of damned if we do, damned if we don't.
I intend to have a fix ready ASAP for netdev-net/main. If all stable branches have all backports, it should apply cleanly everywhere. Just not ready to be included in this series from the start.
Liebe Grüße, Christian
-- Christian Theune - A97C62CE - 0179 7808366 @theuni - christian@theune.cc
Christian Theune wrote:
I can contribute live testing and can quickly reproduce the issue.
If anything is there that should be tested for apart from verifying the fix, I’d be happy to try.
If you perform the repro steps and verify that this solves the issue, that would be helpful, thanks.
Happy to do that. I’ve blocked time tomorrow morning.
On 9. Sep 2024, at 22:32, Willem de Bruijn willemdebruijn.kernel@gmail.com wrote:
Christian Theune wrote:
I can contribute live testing and can quickly reproduce the issue.
If anything is there that should be tested for apart from verifying the fix, I’d be happy to try.
If you perform the repro steps and verify that this solves the issue, that would be helpful, thanks.
Liebe Grüße, Christian
-- Christian Theune - A97C62CE - 0179 7808366 @theuni - christian@theune.cc
Hi,
I just took 5.15.166 + the 4 patches by Willem as they’re currently in the queue. The applied cleanly (which you already tested) and I can demonstrate the known error (bad gso: type: 4, size: 1428) on 5.15.166 without the patches and it’s gone on 5.15.166 with the patches.
Thanks everyone!
Hugs, Christian
On 10. Sep 2024, at 08:32, Christian Theune christian@theune.cc wrote:
Happy to do that. I’ve blocked time tomorrow morning.
On 9. Sep 2024, at 22:32, Willem de Bruijn willemdebruijn.kernel@gmail.com wrote:
Christian Theune wrote:
I can contribute live testing and can quickly reproduce the issue.
If anything is there that should be tested for apart from verifying the fix, I’d be happy to try.
If you perform the repro steps and verify that this solves the issue, that would be helpful, thanks.
Liebe Grüße, Christian
-- Christian Theune - A97C62CE - 0179 7808366 @theuni - christian@theune.cc
Liebe Grüße, Christian
-- Christian Theune - A97C62CE - 0179 7808366 @theuni - christian@theune.cc
On Wed, Sep 11, 2024 at 09:39:01AM +0200, Christian Theune wrote:
Hi,
I just took 5.15.166 + the 4 patches by Willem as they’re currently in the queue. The applied cleanly (which you already tested) and I can demonstrate the known error (bad gso: type: 4, size: 1428) on 5.15.166 without the patches and it’s gone on 5.15.166 with the patches.
Thanks for testing!
linux-stable-mirror@lists.linaro.org
-
Christian Theune -
Greg KH -
Willem de Bruijn -
Willem de Bruijn