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  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:	Wed, 21 Dec 2011 17:14:05 -0800
From:	Vijay Subramanian <>
To:	David Miller <>
Subject: Re: [PATCH net-next] tcp: Fix bug in ofo queue pruning MIB stats

On 21 December 2011 16:33, David Miller <> wrote:
> From: Vijay Subramanian <>
> Date: Wed, 21 Dec 2011 15:50:01 -0800
>> Linux MIB LINUX_MIB_OFOPRUNED is supposed to count the number of packets
>> dropped from the out-of-order queue due to socket buffer overrun. Instead
>> of counting the number of skbs freed, it counts the number of calls make to
>> __skb_queue_purge() which is not what the user (see f.e. netstat) is expecting.
>> Fix this by  incrementing the counter correctly.
>> Signed-off-by: Vijay Subramanian <>
> I disagree, this is an event, and the counter is counting how many times
> we prune the out of order queue, not how many packets we prune from that
> queue.

Thank you for the review.

The reason I felt this was a bug was because of what netstat reports.
Here are 2 sample output lines from netstat.

622 packets pruned from receive queue because of socket buffer overrun
7 packets dropped from out-of-order queue because of socket buffer
overrun   --> (from LINUX_MIB_OFOPRUNED)

netstat is interpreting this incorrectly if the mib counter is
supposed to be tracking events.

Also, LINUX_MIB_OFOPRUNED is named similarly to counters that track
dropped packets (e.g.LINUX_MIB_RCVPRUNED ) than counters that track
events such as a function call (e.g LINUX_MIB_PRUNECALLED). I realize
the naming scheme is not a clinching argument  but taken with what
netstat reports, the intent seems to be to track dropped packets.

If the counter is tracking the right thing, is it worth fixing
netstat? The nstat tool in iproute2 tool does not print any
explanatory text in the output, so there is less chance of confusion
there.  Maybe we just use the newer nstat and forget about this?

Thanks for your time.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists