On Tue, Jun 17, 2025 at 02:25:02PM -0400, Willem de Bruijn wrote:
On Tue, Jun 17, 2025 at 1:29 PM Brett Sheffield brett@librecast.net wrote:
Hi Greg,
On 2025-06-17 15:47, Greg KH wrote:
On Wed, Jun 11, 2025 at 01:04:29PM +0200, Brett Sheffield wrote:
Longterm kernel 6.12.y backports commit:
- a18dfa9925b9ef6107ea3aa5814ca3c704d34a8a "ipv6: save dontfrag in cork"
It's also in older kernels: 5.10.238 5.15.185 6.1.141 6.6.93
but does not backport these related commits:
- 54580ccdd8a9c6821fd6f72171d435480867e4c3 "ipv6: remove leftover ip6 cookie initializer"
- 096208592b09c2f5fc0c1a174694efa41c04209d "ipv6: replace ipcm6_init calls with ipcm6_init_sk"
This causes a regression when sending IPv6 UDP packets by preventing fragmentation and instead returning EMSGSIZE. I have attached a program which demonstrates the issue.
Thanks for the analysis. I had received a report and was looking into it, but had not yet figured out this root cause.
Should we backport thse two to all of the other branches as well?
I have confirmed the regression is present in all of those older kernels (except 5.15.185 as that didn't boot on my test hardware - will look at that later).
The patch appears to have been autoselected for applying to the stable tree:
https://lore.kernel.org/all/?q=a18dfa9925b9ef6107ea3aa5814ca3c704d34a8a
The patch follows on from a whole series of patches by Willem de Bruijn (CC), the rest of which were not applied.
Unless there is a good reason for applying this patch in isolation, the quickest fix is simply to revert that commit in stable and this fixes the regression.
Alternatives are:
- apply a small fix for the regression (patch attached). This leaves a footgun
if you later decide to backport more of the series.
- to backport and test the whole series of patches. See merge commit
aefd232de5eb2e77e3fc58c56486c7fe7426a228
- In the case of 6.12.33, the two patches I referenced apply cleanly and are enough
to fix the problem. There are conflicts on the other branches.
Unless there is a specific reason to have backported a18dfa9925b9ef6107ea3aa5814ca3c704d34a8a to stable I'd suggest just reverting it.
FWIW, I did not originally intend for these changes to make it to stable.
The simplest short term solution is to revert this patch out of the stable trees. But long term that may give more conflicts as later patches need to be backported? Not sure what is wiser in such cases.
For now, I've applied the above 2 to the 6.12.y tree. They do not apply any older. If I should drop the change from the older stable trees, please let me know.
thanks,
greg k-h