netdev - Re: [RFC PATCH] sock: add SO_RCVQUEUE

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:   Mon, 13 Mar 2017 12:38:39 -0500
From:   Josh Hunt <johunt@...mai.com>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     David Miller <davem@...emloft.net>, Arnd Bergmann <arnd@...db.de>,
        Soheil Hassas Yeganeh <soheil@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, linux-arch@...r.kernel.org,
        netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH] sock: add SO_RCVQUEUE_SIZE getsockopt

On 03/13/2017 11:12 AM, Eric Dumazet wrote:
> On Mon, Mar 13, 2017 at 8:59 AM, Josh Hunt <johunt@...mai.com> wrote:
>> Allows application to read the amount of data sitting in the receive
>> queue.
>>
>> Signed-off-by: Josh Hunt <johunt@...mai.com>
>> ---
>>
>> A team here is looking for a way to get the amount of data in a UDP socket's
>> receive queue. It seems like this should be SIOCINQ, but for UDP sockets that
>> returns the size of the next pending datagram. I implemented the patch below,
>> but am wondering if this is the right place for this change? I was debating
>> between this or a new UDP ioctl.
>
> But what is the 'amount of data' exactly ?
> Number of packets, amount of bytes to read from these packets ?

I meant bytes. I will clarify in the next version.

>
> You chose to report kernel memory usage, which is not guaranteed to be
> the same among kernels versions (or kernel configs)
>
> If we export these internals, I would export the whole thing, like we
> did with netlink
>
> ie tweak sock_diag_put_meminfo() and export the SK_MEMINFO_VARS
>
> So that we avoid adding other options in the future.
>

OK, so you're suggesting we provide all of the SK_MEMINFO_VARS data via 
socket option then? That sounds good to me. I will send that in a v2.

Josh