From: David Howells <dhowells@redhat.com>
To: netdev@vger.kernel.org
Cc: dhowells@redhat.com, tim@electronghost.co.uk,
linux-afs@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: [PATCH 3/8] af_rxrpc: Fix UDP MTU calculation from ICMP_FRAG_NEEDED [ver #2]
Date: Thu, 06 Mar 2014 12:46:36 +0000 [thread overview]
Message-ID: <20140306124636.16645.23202.stgit@warthog.procyon.org.uk> (raw)
In-Reply-To: <20140306124614.16645.50744.stgit@warthog.procyon.org.uk>
AF_RXRPC sends UDP packets with the "Don't Fragment" bit set in an attempt to
determine the maximum packet size between the local socket and the peer by
invoking the generation of ICMP_FRAG_NEEDED packets.
Once a packet is sent with the "Don't Fragment" bit set, it is then
inconvenient to break it up as that requires recalculating all the rxrpc serial
and sequence numbers and reencrypting all the fragments, so we switch off the
"Don't Fragment" service temporarily and send the bounced packet again. Future
packets then use the new MTU.
That's all fine. The problem lies in rxrpc_UDP_error_report() where the code
that deals with ICMP_FRAG_NEEDED packets lives. Packets of this type have a
field (ee_info) to indicate the maximum packet size at the reporting node - but
sometimes ee_info isn't filled in and is just left as 0 and the code must allow
for this.
When ee_info is 0, the code should take the MTU size we're currently using and
reduce it for the next packet we want to send. However, it takes ee_info
(which is known to be 0) and tries to reduce that instead.
This was discovered by Coverity.
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/ar-error.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/rxrpc/ar-error.c b/net/rxrpc/ar-error.c
index a9206087b4d7..db57458c824c 100644
--- a/net/rxrpc/ar-error.c
+++ b/net/rxrpc/ar-error.c
@@ -83,6 +83,7 @@ void rxrpc_UDP_error_report(struct sock *sk)
if (mtu == 0) {
/* they didn't give us a size, estimate one */
+ mtu = peer->if_mtu;
if (mtu > 1500) {
mtu >>= 1;
if (mtu < 1500)
next prev parent reply other threads:[~2014-03-06 12:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 12:46 [PATCH 0/8] AF_RXRPC fixes and development " David Howells
2014-03-06 12:46 ` [PATCH 1/8] af_rxrpc: Remove incorrect checksum calculation from rxrpc_recvmsg() " David Howells
2014-03-06 12:46 ` [PATCH 2/8] af_rxrpc: Prevent RxRPC peers from ABORT-storming one another " David Howells
2014-03-06 12:46 ` David Howells [this message]
2014-03-06 12:46 ` [PATCH 4/8] af_rxrpc: Add sysctls for configuring RxRPC parameters " David Howells
2014-03-06 12:46 ` [PATCH 5/8] af_rxrpc: Improve ACK production " David Howells
2014-03-06 12:46 ` [PATCH 6/8] af_rxrpc: Expose more RxRPC parameters via sysctls " David Howells
2014-03-06 12:47 ` [PATCH 7/8] af_rxrpc: Request an ACK for every alternate DATA packet " David Howells
2014-03-06 12:47 ` [PATCH 8/8] af_rxrpc: Keep rxrpc_call pointers in a hashtable " David Howells
2014-03-06 19:37 ` [PATCH 0/8] AF_RXRPC fixes and development " David Miller
2014-03-06 22:15 ` David Howells
2014-03-06 22:16 ` David Miller
2014-03-06 22:31 ` David Howells
2014-03-07 21:12 ` David Miller
2014-03-06 22:32 ` David Howells
2014-03-06 22:38 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140306124636.16645.23202.stgit@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=linux-afs@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tim@electronghost.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome