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:	Tue, 25 Aug 2009 18:48:53 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
CC:	Sridhar Samudrala <sri@...ibm.com>,
	Nivedita Singhvi <niv@...ibm.com>, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: UDP multicast packet loss not reported if TX ring overrun?

Christoph Lameter a écrit :
> On Tue, 25 Aug 2009, Eric Dumazet wrote:
> 
>>> I read this just yesterday. IP_RECVERR means that the application wants to
>>> see details on each loss. We just want some counters that give us accurate
>>> statistics to gauge where packet loss is occurring. Applications are
>>> usually not interested in tracking the fate of each packet.
>> Yep,  but IP_RECVERR also has the side effect of letting kernel returns -ENOBUFS error
>> in sending and congestion, which was your initial point :)
> 
> The initial point was that the SNMP counters are not updated if IP_RECVERR
> is not set which is clearly a bug and your and my patch addresses that.

Technically speaking, the send() syscall is in error. Frame is not sent, so
there is no drop at all. Like trying to send() from a bad user buffer, or write()
to a too big file...


> 
> Then Sridhar noted that there are other tx drop counters. qdisc counters
> are also not updated. Wish we would maintain tx drops counters there as
> well so that we can track down which NIC drops it.
> 
> Then came the wishlist of UDP counters for tx drops and socket based
> tx_drop accounting for tuning and tracking down which app is sending
> too fast .... ;-)
> 
> The apps could be third party apps. Just need to be able to troubleshoot
> packet loss.
> 

Question is : should we just allow send() to return an error (-ENOBUF) regardless
of IP_RECVERR being set or not ? I dont think it would be so bad after all.
Most apps probably dont care, or already handle the error.

diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 7d08210..afae0cb 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1302,7 +1302,7 @@ int ip_push_pending_frames(struct sock *sk)
 	err = ip_local_out(skb);
 	if (err) {
 		if (err > 0)
-			err = inet->recverr ? net_xmit_errno(err) : 0;
+			err = net_xmit_errno(err);
 		if (err)
 			goto error;
 	}
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 87f8419..a7e5f93 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1526,7 +1526,7 @@ int ip6_push_pending_frames(struct sock *sk)
 	err = ip6_local_out(skb);
 	if (err) {
 		if (err > 0)
-			err = np->recverr ? net_xmit_errno(err) : 0;
+			err = net_xmit_errno(err);
 		if (err)
 			goto error;
 	}
--
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