netdev - Re: UDP multicast packet loss not reported if TX ring overrun?

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:	Fri, 28 Aug 2009 17:07:32 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
CC:	Sridhar Samudrala <sri@...ibm.com>,
	David Stevens <dlstevens@...ibm.com>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	niv@...ux.vnet.ibm.com
Subject: Re: UDP multicast packet loss not reported if TX ring overrun?

Christoph Lameter a écrit :
> The qdisc drop counter is incremented in pfifo_fast. So Sridhar's patch is
> not necessary.
> 
> Seems though that the qdisc drop count does not flow into the tx_dropped
> counter for the interface. Incrementing the tx_dropped count in the
> netdev_queue associated with the outbound qdisc also had no effect (see
> the following patch).
> 
> Plus I only see one queue for eth0 with "tc -s qdisc show". I think that
> what I see there is the queue for receiving packets. tc uses this ugly
> netlink interface. Could be a bug in there or in the netlink interface?
> Or is there some other trick to display queue statistics for outgoing
> packets?

"tc -s qdisc show" only displays queue info for tx packets.

> 
> WTH is going on here? Noone was ever interested in making outbound packet
> loss account right?
> 

I have no idea of what your problem can be Christoph.

Here, on unpatched git linux-2.6 kernel, default qdisc, and an udp tx flood I get :

# tc -s -d qdisc show dev eth3
qdisc pfifo_fast 0: root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 18025794122 bytes 17299241 pkt (dropped 264892, overlimits 0 requeues 68282)
 rate 0bit 0pps backlog 20840b 20p requeues 68282



> 
> Index: linux-2.6.31-rc7/include/net/sch_generic.h
> ===================================================================
> --- linux-2.6.31-rc7.orig/include/net/sch_generic.h	2009-08-27
> 21:20:03.000000000 +0000
> +++ linux-2.6.31-rc7/include/net/sch_generic.h	2009-08-27
> 21:26:33.000000000 +0000
> @@ -509,6 +509,9 @@ static inline int qdisc_drop(struct sk_b
>  	kfree_skb(skb);
>  	sch->qstats.drops++;
> 
> +	/* device queue statistics */
> +	sch->dev_queue->tx_dropped++;
> +
>  	return NET_XMIT_DROP;
>  }

locking problem here, tx_dropped can be changed by another cpu.


As David Stevens pointed out, device was not ever called at all when your packet(s) was/were lost.
Why should we account a non existent drop at device level ?

When a process wants a new memory page and hits its own limit, do you want to increment a system global
counter saying 'memory allocation failed' ?


So in my case :

$ ifconfig eth3
eth3      Link encap:Ethernet  HWaddr 00:1E:0B:92:78:51
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1188 errors:0 dropped:0 overruns:0 frame:0
          TX packets:63774907 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:633918 (619.0 KiB)  TX bytes:105287564 (100.4 MiB)
          Interrupt:16

And yes, dropped:0 is OK here, since packets where dropped at qdisc layer.


Only change you want is eventually to account for the UDP drop (SndbufErrors).

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html