Re: [PATCH net] net/sched: act_mirred: use the backlog for mirred ingress

From: Davide Caratti <dcaratti@redhat.com>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
	pabeni@redhat.com,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	xiyou.wangcong@gmail.com, jiri@resnulli.us,
	shmulik.ladkani@gmail.com
Subject: Re: [PATCH net] net/sched: act_mirred: use the backlog for mirred ingress
Date: Wed, 14 Feb 2024 17:10:37 +0100	[thread overview]
Message-ID: <Zczl_QQ200PvyzH5@dcaratti.users.ipa.redhat.com> (raw)
In-Reply-To: <CAM0EoM=sUpX1yOL7yO5Z4UGOakxw1+GK97yqs4U5WyOy7U+SxQ@mail.gmail.com>

On Wed, Feb 14, 2024 at 10:28:27AM -0500, Jamal Hadi Salim wrote:
> On Wed, Feb 14, 2024 at 10:11 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> >
> > On Fri, Feb 9, 2024 at 6:54 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > >
> > > The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog
> > > for nested calls to mirred ingress") hangs our testing VMs every 10 or so
> > > runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by
> > > lockdep.

[...]

> > Doing a quick test of this and other patch i saw..
> 
> 
> So tests pass - but on the list i only see one patch and the other is
> on lore, not sure how to ACK something that is not on email, but FWIW:
> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
> 
> The second patch avoids the recursion issue (which was the root cause)
> and the first patch is really undoing ca22da2fbd693

If I well read, Jakub's patch [1] uses the backlog for egress->ingress
regardless of the "nest level": no more calls to netif_receive_skb():
It's the same as my initial proposal for fixing the OVS soft-lockup [2],
the code is different because now we have tcf_mirred_to_dev().

I'm ok with this solution, and maybe we need to re-think if it's
really a problem to loose the statistics for action subsequent to a
mirred redirect egress->ingress. IMHO it's not a problem to loose them:
if RPS or RX timestamping is enabled on the RX target device, we would
loose this information anyways (maybe this answers to Jiri's question
above in the thread).

The other patch [3] fixes the reported UAF, but if the Fixes: tag is
correct it will probably need some special care if it propagates to
stable branches.

thanks,
-- 
davide

[1] https://lore.kernel.org/netdev/20240209235413.3717039-1-kuba@kernel.org/
[2] https://lore.kernel.org/netdev/33dc43f587ec1388ba456b4915c75f02a8aae226.1663945716.git.dcaratti@redhat.com/ 
[3] https://lore.kernel.org/netdev/20240214033848.981211-2-kuba@kernel.org/