netdev - Re: [PATCH v2] sctp: align MTU to a word

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] [day] [month] [year] [list]

Date:	Sun, 20 Mar 2016 16:31:56 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	marcelo.leitner@...il.com
Cc:	netdev@...r.kernel.org, eric.dumazet@...il.com,
	nhorman@...driver.com, vyasevich@...il.com,
	linux-sctp@...r.kernel.org
Subject: Re: [PATCH v2] sctp: align MTU to a word

From: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Date: Sat, 19 Mar 2016 12:17:20 -0300

> SCTP is a protocol that is aligned to a word (4 bytes). Thus using bare
> MTU can sometimes return values that are not aligned, like for loopback,
> which is 65536 but ipv4_mtu() limits that to 65535. This mis-alignment
> will cause the last non-aligned bytes to never be used and can cause
> issues with congestion control.
> 
> So it's better to just consider a lower MTU and keep congestion control
> calcs saner as they are based on PMTU.
> 
> Same applies to icmp frag needed messages, which is also fixed by this
> patch.
> 
> One other effect of this is the inability to send MTU-sized packet
> without queueing or fragmentation and without hitting Nagle. As the
> check performed at sctp_packet_can_append_data():
> 
> if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead)
> 	/* Enough data queued to fill a packet */
> 	return SCTP_XMIT_OK;
> 
> with the above example of MTU, if there are no other messages queued,
> one cannot send a packet that just fits one packet (65532 bytes) and
> without causing DATA chunk fragmentation or a delay.
> 
> v2:
>  - Added WORD_TRUNC macro
> 
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>

Applied.