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 18:34:41 -0500
From:   Josh Hunt <>
To:     David Miller <>
Subject: Re: [RFC PATCH] sock: add SO_RCVQUEUE_SIZE getsockopt

On 03/13/2017 02:39 PM, David Miller wrote:
> From: Josh Hunt <>
> Date: Mon, 13 Mar 2017 12:38:39 -0500
>> On 03/13/2017 11:12 AM, Eric Dumazet wrote:
>>> On Mon, Mar 13, 2017 at 8:59 AM, Josh Hunt <> wrote:
>>>> Allows application to read the amount of data sitting in the receive
>>>> queue.
>>>> Signed-off-by: Josh Hunt <>
>>>> ---
>>>> 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.
> As Eric is hinting, the calculation you are using doesn't represent
> this.
> You need to do something like walk the receive queue and add the
> skb->len values together.
> sk->sk_rmem_alloc is usually much larger than the sum of the skb->len
> values in the socket receive queue.  I don't see how this culmination
> of skb->truesize values is useful, whereas I can see how an application
> could want the summation of the skb->len values.

In this particular case they really do want to know total # of bytes in 
the receive queue, not the data bytes they can consume from an 
application pov. The kernel currently only exposes this value through 
netlink or /proc/net/udp from what I saw.

I believe Eric's suggestion in his previous mail was to export all of 
these meminfo metrics via a single socket option call similar to how its 
done in netlink. We could then use that for both call sites.

I agree that it would be useful to also have the data you and Eric are 
suggesting exposed somewhere, the total # of skb->len bytes sitting in 
the receive queue. I could add that as a second socket option.

Does this sound reasonable?


Powered by blists - more mailing lists