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]

Message-Id: <1251225500.3169.38.camel@w-sridhar.beaverton.ibm.com>
Date:	Tue, 25 Aug 2009 11:38:20 -0700
From:	Sridhar Samudrala <sri@...ibm.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	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?

On Tue, 2009-08-25 at 18:48 +0200, Eric Dumazet wrote:
> 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.

This patch would allow tracking drops at UDP level too via UDP_MIB_SNDBUFERRORS
that is incremented in udp_sendmsg(). Right now this happens only if IP_RECVERR
is set on the socket.

Ideally, it would be good to track the drops at qdisc, IP and UDP if a
packet is passed all the way to dev_queue_xmit() and then dropped.

Thanks
Sridhar


> 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