[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y87CY5aQwZAcVU1A@t14s.localdomain>
Date: Mon, 23 Jan 2023 14:22:43 -0300
From: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To: Davide Caratti <dcaratti@...hat.com>
Cc: jhs@...atatu.com, jiri@...nulli.us, lucien.xin@...il.com,
netdev@...r.kernel.org, pabeni@...hat.com, wizhao@...hat.com,
xiyou.wangcong@...il.com
Subject: Re: [PATCH net-next 2/2] act_mirred: use the backlog for nested
calls to mirred ingress
On Fri, Jan 20, 2023 at 06:01:40PM +0100, Davide Caratti wrote:
> William reports kernel soft-lockups on some OVS topologies when TC mirred
> egress->ingress action is hit by local TCP traffic [1].
> The same can also be reproduced with SCTP (thanks Xin for verifying), when
> client and server reach themselves through mirred egress to ingress, and
> one of the two peers sends a "heartbeat" packet (from within a timer).
>
> Enqueueing to backlog proved to fix this soft lockup; however, as Cong
> noticed [2], we should preserve - when possible - the current mirred
> behavior that counts as "overlimits" any eventual packet drop subsequent to
> the mirred forwarding action [3]. A compromise solution might use the
> backlog only when tcf_mirred_act() has a nest level greater than one:
> change tcf_mirred_forward() accordingly.
>
> Also, add a kselftest that can reproduce the lockup and verifies TC mirred
> ability to account for further packet drops after TC mirred egress->ingress
> (when the nest level is 1).
>
> [1] https://lore.kernel.org/netdev/33dc43f587ec1388ba456b4915c75f02a8aae226.1663945716.git.dcaratti@redhat.com/
> [2] https://lore.kernel.org/netdev/Y0w%2FWWY60gqrtGLp@pop-os.localdomain/
> [3] such behavior is not guaranteed: for example, if RPS or skb RX
> timestamping is enabled on the mirred target device, the kernel
> can defer receiving the skb and return NET_RX_SUCCESS inside
> tcf_mirred_forward().
>
> Reported-by: William Zhao <wizhao@...hat.com>
> CC: Xin Long <lucien.xin@...il.com>
> Signed-off-by: Davide Caratti <dcaratti@...hat.com>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Powered by blists - more mailing lists