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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 3/3/23 10:33, Florian Westphal wrote:

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.

Okay, I agree with this, and thanks again the quick fix here.

When we could expect this in the mainline or 5.15 LTS?

Should I do someting further with the bugzilla ticket 1662?

[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux