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: <alpine.DEB.1.10.0908251340510.26329@gentwo.org>
Date:	Tue, 25 Aug 2009 13:44:20 -0400 (EDT)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Eric Dumazet <eric.dumazet@...il.com>
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?

On Tue, 25 Aug 2009, Eric Dumazet wrote:

> Christoph Lameter a ?crit :
> > On Tue, 25 Aug 2009, Eric Dumazet wrote:
> >
> >>> 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...
> >
> > Frame is submitted to the IP layer which discards it. That is the
> > definition of an output discard.
> >
>
> Last patch accounts for this *error* AFAIK, or did I missed something ?

Right.

> >> 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.
> >
> > Some applications will then start to fail because so far you can send with
> > impunity without getting errors. AFAICT IP_RECVERR was added to preserve
> > that behavior. Your patch is changing basic send() semantics.
>
> Sorry ???, I guess your machines have plenty available LOWMEM then, and kmalloc() never fail then...

Nope. Currently sendto() just drops the packet and returns success if the
TX ring is full. That can be done ad infinitum and at very high traffic
rates. We had one person here believing he could send 800k 300 byte
packets per second on a 1G wire.... ROTFL.

> basic send() semantics are respected.

basic send() semantics are changed by your patch. The 800k pps would no
longer work without sendto() returning errors.

--
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