Re: CPU soft lockup in a spin lock using tproxy and nfqueue

[Florian Westphal <fw@strlen.de>]

Major Dávid <major.david@balasys.hu> wrote:
> On 3/3/23 01:09, Florian Westphal wrote:
> > 
> > Which one?  As far as I can see TCP stack would end up adding a
> > duplicate quadruple to the hash if we only drop the reference and
> > keep the listen sk around.
> 
> I just thought that tcp_timewait_state_process is called by TCP stack to
> handle TW state, which actually call inet_twsk_deschedule_put parallel to tproxy and
> that would be the root cause of the deadlock.

No, it won't be called.

We can do two things:
1. Assign the tw sk to skb->sk, then its handled by
   tcp_timewait_state_process() in tcp stack.

Problem is that after the tw sk was handled, tcp stack won't find
a listener socket if the tproxy service is running on a different port.

2. Assign the listener socket to skb->sk (this is whats done now).

> So I guess now, basically we would leak away the tw socket if we do not call put in tproxy?

We could just drop the reference, but then, as far as i can see, we end
up with two identical connection entries in the ehash table.