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

On Tue, Jan 25, 2011 at 1:48 PM, David Miller <> wrote:
> 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)

Yes I also tried to trace how long the bug has been there and it seems
to go back to the prehistoric era :). Guess only TCP types got alarmed
by spurious RSTs.


> Good work, applied, thanks!

      reply	other threads:[~2011-01-25 23:48 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
2011-01-25 23:48   ` Jerry Chu [this message]

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 \
    --in-reply-to='' \ \ \ \

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