Hi Salvatore,
Thank you for your guidance and for pointing out the relevant commit.
I have tested, checking out from tag 6.1.134:
- With the revert of commit b88786ea2c8f ("tunnels: Accept PACKET_HOST in
skb_tunnel_check_pmtu()"): the issue does not appear and everything works as
expected
- With the commit included (no revert), the issue reappears exactly as before.
This confirms that the regression is directly linked to this commit.
Is there anything else I can do or provide to help with the resolution?
Thanks,
- Charles
On Thu, Jul 10, 2025, at 20:56, Salvatore Bonaccorso wrote:
> control: tags -1 + moreinfo
>
> Hi Charles,
>
> On Sun, Jul 06, 2025 at 08:59:46PM +0200, Salvatore Bonaccorso wrote:
>> Hi Charles,
>>
>> On Sun, Jul 06, 2025 at 07:43:35PM +0200, rough.rock3...@datachamp.fr wrote:
>> > Hi,
>> >
>> > Thank you for the quick reply.
>> >
>> > We tried kernel versions 6.12.35-1 from unstable and 6.15.4-1 from
>> > experimental and the issue still appears on both versions.
>>
>> Ack, thanks for confirming that, I just updated the bug metadata to
>> reflect that.
>>
>> > We are currently bisecting the changes to identify the commit. This
>> > will take several days as the server is used in production and we
>> > need to minimize downtime during working hours. I will get back to
>> > this issue as soon as the commit is identified.
>>
>> Yes that is fully understandable. Would be ideal if that can be
>> reproduced under lab conditions, but then this takes just the time it
>> needs.
>>
>> Ping us back once you have identified the breaking commit.
>>
>> Thanks for your debugging.
>
> I'm not sure where you are right now at the bisect. But yesterday in
> our weekly kernel-team meeting we talked about your issue. And Ben
> pointed out that he saw recently a PMTU related change.
>
> And in fact htere is 8930424777e4 ("tunnels: Accept PACKET_HOST in
> skb_tunnel_check_pmtu().") which is from 6.15-rc1. And it got
> backported to various stable series, for your report of interest is
> that it was backported to 6.1.134, which falls exactly in the range
> you noticed of breaking.
>
> Thus: are you able to test first at all 6.1.y and a revert of the
> given commit on top and see if that fixes your issue?
>
> Regards,
> Salvatore
