netdev - Re: [PATCH V2 net-next 1/2] tcp: send in-queue bytes in cmsg upon read

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]

Message-ID: <c95883da-51ab-47aa-7ad1-a5bb85935e6b@gmail.com>
Date:   Mon, 30 Apr 2018 09:01:47 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     David Miller <davem@...emloft.net>, eric.dumazet@...il.com
Cc:     soheil.kdev@...il.com, netdev@...r.kernel.org, ycheng@...gle.com,
        ncardwell@...gle.com, edumazet@...gle.com, willemb@...gle.com,
        soheil@...gle.com
Subject: Re: [PATCH V2 net-next 1/2] tcp: send in-queue bytes in cmsg upon
 read



On 04/30/2018 08:56 AM, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@...il.com>
> Date: Mon, 30 Apr 2018 08:43:50 -0700
> 
>> I say sort of, because by the time we have any number, TCP might
>> have received more packets anyway.
> 
> That's fine.
> 
> However, the number reported should have been true at least at some
> finite point in time.
> 
> If you allow overlapping changes to either of the two variables during
> the sampling, then you are reporting a number which was never true at
> any point in time.
> 
> It is essentially garbage.


Correct.

TCP sockets are read by a single thread really (or synchronized threads),
or garbage is ensured, regardless of how the kernel ensures locking while reporting "queue length"