netdev - Re: Compare length of req sock queue with sk_max_ack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 01 Feb 2018 06:00:07 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Tonghao Zhang <xiangxia.m.yue@...il.com>,
        Eric Dumazet <edumazet@...gle.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Compare length of req sock queue with sk_max_ack_backlog

On Thu, 2018-02-01 at 20:34 +0800, Tonghao Zhang wrote:
> Hi Eric
> One question for you, In the patch ef547f2ac16 ("tcp: remove
> max_qlen_log"),  why we compared the length of req sock queue with
> sk_max_ack_backlog. If we remove the max_qlen_log, we should check the
> length of req sock queue with tcp_max_syn_backlog, right ?
> 
> With this patch, the option "/proc/sys/net/ipv4/tcp_max_syn_backlog"
> will be unsed anymore, right ?

Not right.

Please "git grep -n sysctl_max_syn_backlog" to convince it is still
used.

> 
> I hope we should
> 1. Add a variate in sock struct, such as sk_max_syn_backlog. Then req
> sock queue and accept sock queue can control their max value. When we
> create the sock, we can store the tcp_max_syn_backlog value to
> sk_max_syn_backlog.
> 

There is a single /proc/sys/net/ipv4/tcp_max_syn_backlog value shared
by all sockets of a given network namespace.

But you can have thousands of TCP listeners, each of them having a
distinct listen() backlog

> 2. Update the backlog, we can update it via ioctl.

No need to add an ugly ioctl.

Simply call listen() again with another backlog value.