All of
 help / color / mirror / Atom feed
From: David Miller <>
Subject: Re: [PATCH] TCP: fix a bug that triggers large number of TCP RST by mistake
Date: Tue, 25 Jan 2011 13:48:16 -0800 (PST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

From: "H.K. Jerry Chu" <>
Date: Sat, 22 Jan 2011 11:06:17 -0800

> From: Jerry Chu <>
> This patch fixes a bug that causes TCP RST packets to be generated
> on otherwise correctly behaved applications, e.g., no unread data
> on close,..., etc. To trigger the bug, at least two conditions must
> be met:
> 1. The FIN flag is set on the last data packet, i.e., it's not on a
> separate, FIN only packet.
> 2. The size of the last data chunk on the receive side matches
> exactly with the size of buffer posted by the receiver, and the
> receiver closes the socket without any further read attempt.
> This bug was first noticed on our netperf based testbed for our IW10
> proposal to IETF where a large number of RST packets were observed.
> netperf's read side code meets the condition 2 above 100%.
> Before the fix, tcp_data_queue() will queue the last skb that meets
> condition 1 to sk_receive_queue even though it has fully copied out
> (skb_copy_datagram_iovec()) the data. Then if condition 2 is also met,
> tcp_recvmsg() often returns all the copied out data successfully
> without actually consuming the skb, due to a check
> "if ((chunk = len - tp->ucopy.len) != 0) {"
> and
> "len -= chunk;"
> after tcp_prequeue_process() that causes "len" to become 0 and an
> early exit from the big while loop.
> I don't see any reason not to free the skb whose data have been fully
> consumed in tcp_data_queue(), regardless of the FIN flag.  We won't
> get there if MSG_PEEK is on. Am I missing some arcane cases related
> to urgent data?
> Signed-off-by: H.K. Jerry Chu <>

This bug goes as far back as January, 2000 right after the softnet
mega-merge happened via the netdev CVS tree (netdev-vger-cvs GIT
commit 214d457e)

Good work, applied, thanks!

  reply	other threads:[~2011-01-25 21:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-22 19:06 [PATCH] TCP: fix a bug that triggers large number of TCP RST by mistake H.K. Jerry Chu
2011-01-25 21:48 ` David Miller [this message]
2011-01-25 23:48   ` Jerry Chu

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.