Message-ID: <87ad31d7-2ef6-47ca-be31-2ba2ac85d708@uliege.be>
Date: Tue, 25 Feb 2025 19:36:47 +0100
From: Justin Iurman <justin.iurman@...ege.be>
To: Ido Schimmel <idosch@...sch.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net, dsahern@...nel.org,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
 Alexander Aring <alex.aring@...il.com>, David Lebrun <dlebrun@...gle.com>
Subject: Re: [PATCH net v2 2/3] net: ipv6: fix lwtunnel loops in ioam6, rpl
 and seg6

On 2/16/25 17:31, Ido Schimmel wrote:
> On Thu, Feb 13, 2025 at 11:51:49PM +0100, Justin Iurman wrote:
>> On 2/13/25 14:28, Ido Schimmel wrote:
>>> On Tue, Feb 11, 2025 at 11:16:23PM +0100, Justin Iurman wrote:
>>>> When the destination is the same post-transformation, we enter a
>>>> lwtunnel loop. This is true for ioam6_iptunnel, rpl_iptunnel, and
>>>> seg6_iptunnel, in both input() and output() handlers respectively, where
>>>> either dst_input() or dst_output() is called at the end. It happens for
>>>> instance with the ioam6 inline mode, but can also happen for any of them
>>>> as long as the post-transformation destination still matches the fib
>>>> entry. Note that ioam6_iptunnel was already comparing the old and new
>>>> destination address to prevent the loop, but it is not enough (e.g.,
>>>> other addresses can still match the same subnet).
>>>>
>>>> Here is an example for rpl_input():
>>>>
>>>> dump_stack_lvl+0x60/0x80
>>>> rpl_input+0x9d/0x320
>>>> lwtunnel_input+0x64/0xa0
>>>> lwtunnel_input+0x64/0xa0
>>>> lwtunnel_input+0x64/0xa0
>>>> lwtunnel_input+0x64/0xa0
>>>> lwtunnel_input+0x64/0xa0
>>>> [...]
>>>> lwtunnel_input+0x64/0xa0
>>>> lwtunnel_input+0x64/0xa0
>>>> lwtunnel_input+0x64/0xa0
>>>> lwtunnel_input+0x64/0xa0
>>>> lwtunnel_input+0x64/0xa0
>>>> ip6_sublist_rcv_finish+0x85/0x90
>>>> ip6_sublist_rcv+0x236/0x2f0
>>>>
>>>> ... until rpl_do_srh() fails, which means skb_cow_head() failed.
>>>>
>>>> This patch prevents that kind of loop by redirecting to the origin
>>>> input() or output() when the destination is the same
>>>> post-transformation.
>>>
>>> A loop was reported a few months ago with a similar stack trace:
>>> https://lore.kernel.org/netdev/2bc9e2079e864a9290561894d2a602d6@akamai.com/
>>>
>>> But even with this series applied my VM gets stuck. Can you please check
>>> if the fix is incomplete?
>>
>> Good catch! Indeed, seg6_local also needs to be fixed the same way.
>>
>> Back to my first idea: maybe we could directly fix it in lwtunnel_input()
>> and lwtunnel_output() to make our lives easier, but we'd have to be careful
>> to modify all users accordingly. The users I'm 100% sure that are concerned:
>> ioam6 (output), rpl (input/output), seg6 (input/output), seg6_local (input).
>> Other users I'm not totally sure (to be checked): ila (output), bpf (input).
>>
>> Otherwise, we'll need to apply the fix to each user concerned (probably the
>> safest (best?) option right now). Any opinions?
> 
> I audited the various lwt users and I agree with your analysis about
> which users seem to be effected by this issue.
> 
> I'm not entirely sure how you want to fix this in
> lwtunnel_{input,output}() given that only the input()/output() handlers
> of the individual lwt users are aware of both the old and new dst
> entries.

Right. The idea was to compare "orig_dst" with "new dst" before/after a 
call to input()/output() in lwtunnel_input()/lwtunnel_output(). Which, 
of course, would require to modify each of those input/output handlers 
respectively, so that they don't call dst_input()/dst_output() nor 
orig_input()/orig_output() anymore. Would be easier to apply the fix at 
that level, instead of each one by one.

Powered by blists - more mailing lists