[Net/TCP] AcceptQueue timeout mechanism bug.

[JiaHuann]

Description

Hi, Developers and Maintainers, I am a newbie for Networking,
I am using a little lower kernel as a client to curl to gVisor sandbox inside the k8s but found the e.acceptQueue will be quickly fullfield.After that, gVisor using synCookies that correct.
However, after a long time ,the acceptQueue is still full(I have turned off the curl), and I still find that content in the queue.

I think it is because of the conflict between the low version kernel netstack implementation and the operation in gVisor.

		if h.ep.SendTSOk && !s.parsedOptions.TS {
			h.ep.stack.Stats().DroppedPackets.Increment()
			return nil
		}

But, this is not a problem. The real question is, because of this type of dropping package, the execute path will nerver go to delete as below：

delete(lEP.acceptQueue.pendingEndpoints, ep)

Whenever I use div to set break and to do some observation , always full like the pic belowing:

I think it might be a bug?

Thanks for your time to analyze and reply！

Steps to reproduce

using 3.10.107 version kernel as client to curl any service which is exposed
And client must send package without timestamp option.

runsc version

runsc version release-20250113.0
spec: 1.1.0-rc.1

uname

5.4.241 (on pod mother machine)

[milantracy]

I don't understand using 3.10.107 version kernel as client in reproduce steps

Can you reproduce the issue from a different Linux kernel version?

[JiaHuann]

I don't understand using 3.10.107 version kernel as client in reproduce steps

Can you reproduce the issue from a different Linux kernel version?

ok，milantracy，thanks for your reply, i will recognize my question in a new issue with more info and details.
Thanks.