netdev - Re: IPoIB: Fix multicast packet drops before join is complete

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: <20090603.224104.222901210.davem@davemloft.net>
Date:	Wed, 03 Jun 2009 22:41:04 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	cl@...ux-foundation.org
Cc:	rdreier@...co.com, netdev@...r.kernel.org, yosefe@...taire.COM
Subject: Re: IPoIB: Fix multicast packet drops before join is complete

From: Christoph Lameter <cl@...ux-foundation.org>
Date: Tue, 2 Jun 2009 10:49:21 -0400 (EDT)

> IPoIB: Fix multicast packet drops before join is complete
> 
> The IPoIB layer drops multicast packets after queueing 3 as long as a
> multicast group is not ready. The multicast group not being ready may
> occur on first use or after a period of silence on a MC group.
> 
> What should happen is that packet are queued up until the maximum queue
> size is reached (set by sk_sndbuf). Then the socket layer would put
> the sending process to sleep until space in the queue becomes available
> (after the multicast group becomes ready and after the initial messages
> have been sent).
> 
> With the IPoIB layer dropping packets this does not occur. The process
> can continue sending multicast packets and they are all dropped until
> the multicast group becomes ready. The receiver will see the initial 3
> multicast packets that have been significantly delayed, then a large
> gap of missing packet before getting packets that have not been delayed.
> 
> After this patch the socket queue will build up and the sender will be
> throttled until the MC group becomes ready.
> 
> If old behavior is desired then the application can configure
> the send queue size to only allow 3 packet and specify MSG_DONTWAIT
> for send operations.
> 
> Signed-off-by: Christoph Lameter <cl@...ux-foundation.org>

I don't think using an infinite backlog for this is wise.

We don't do this for ARP, for example.  We have a 3 packet limit just
like IPoIB implements for multicast here.

I'm all for increasing those limits, but eliminating them I cannot
agree with.
--
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