From: Ttttabcd <redacted>
Date: Tue, 31 Dec 2019 01:21:47 +0000

In the original logic of tcp_conn_request, the backlog parameter of the
listen system call and net.ipv4.tcp_max_syn_backlog are independent of
each other, which causes some confusion in the processing.

The backlog determines the maximum length of request_sock_queue, hereafter
referred to as backlog.

In the original design, if syn_cookies is not turned on, a quarter of
tcp_max_syn_backlog will be reserved for clients that have proven to
exist, mitigating syn attacks.

Suppose now that tcp_max_syn_backlog is 1000, but the backlog is only 200,
then 1000 >> 2 = 250, the backlog is used up by the syn attack, and the
above mechanism will not work.

Is tcp_max_syn_backlog used to limit the
maximum length of request_sock_queue?

Now suppose sycookie is enabled, backlog is 1000, and tcp_max_syn_backlog
is only 200. In this case tcp_max_syn_backlog will be useless.

Because syn_cookies is enabled, the tcp_max_syn_backlog logic will
be ignored, and the length of request_sock_queue will exceed
tcp_max_syn_backlog until the backlog.

I modified the original logic and set the minimum value in backlog and
tcp_max_syn_backlog as the maximum length limit of request_sock_queue.

Now there is only a unified limit.

The maximum length limit variable is "max_syn_backlog".

Use syn_cookies whenever max_syn_backlog is exceeded.

If syn_cookies is not enabled, a quarter of the max_syn_backlog queue is
reserved for hosts that have proven to exist.

In any case, request_sock_queue will not exceed max_syn_backlog.
When syn_cookies is not turned on, a quarter of the queue retention
will not be preempted.

Signed-off-by: AK Deng <redacted>

On the surface this looks fine to me, but I'll give Eric a chance to
review and give feedback.

Thank you.