netdev - Re: [PATCH net-next 1/1] inet_diag: fetch cong algo info when socket is destroyed

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] [day] [month] [year] [list]

Date:   Mon, 30 Apr 2018 13:33:23 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     David Miller <davem@...emloft.net>
Cc:     kraig@...gle.com, netdev@...r.kernel.org, eric.dumazet@...il.com,
        kernel@...atatu.com, hadi@...atatu.com
Subject: Re: [PATCH net-next 1/1] inet_diag: fetch cong algo info when socket
 is destroyed

On 29/04/18 08:31 PM, David Miller wrote:

> Well, two things:
> 
> 1) The congestion control info is opt-in, meaning that the user gets
>     it in the dump if they ask for it.
> 
>     This information is opt-in, because otherwise the dumps get really
>     large.
> 
>     Therefore, emitting this stuff by default on destroys in a
>     non-starter.
> 

There are two options that I investigated:
Add a setsockopt() for a new group that indicate "give me the congestion
info in addition" or add a similar knob at bind() time. Either of those
approaches would require bigger surgeries. If you think either of those
is reasonable i will work in that direction.

Note: Vegas adds 4 32-bit words; BBR 5 32-bit words; the congestion
name another 16B worst case.
In the larger scope of things that is very small extra data and saves
all the complexity of the other approaches.

> 2) The TCP_TIME_WAIT test is not there for looks.  You need to add it
>     also to the destroy case, and guess what?  All the sockets you will
>     see will not pass that test.
> 

The TCP_TIME_WAIT test makes sense for a live socket. This sock is
past that stage.

> I'm not applying this, sorry.  I really think things are go as-is, and
> if you really truly want the congestion control information you can
> ask for it while the socket is still alive, and is in the proper state
> to sample the congestion control state before you kill it off.

I am avoiding the polling for scaling reasons. It worked fine for
small number of sockets.

cheers,
jamal