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?
