netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Julius Werner <jwerner@chromium.org>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	Patrick McHardy <kaber@trash.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	James Morris <jmorris@namei.org>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	"David S. Miller" <davem@davemloft.net>,
	Sameer Nanda <snanda@chromium.org>,
	Mandeep Singh Baines <msb@chromium.org>,
	Eric Dumazet <edumazet@chromium.org>
Subject: Re: [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crash
Date: Tue, 6 Nov 2012 20:39:07 -0500	[thread overview]
Message-ID: <20121107013907.GA31185@redhat.com> (raw)
In-Reply-To: <1352247335-10396-1-git-send-email-jwerner@chromium.org>

On Tue, Nov 06, 2012 at 04:15:35PM -0800, Julius Werner wrote:
 > tcp_recvmsg contains a sanity check that WARNs when there is a gap
 > between the socket's copied_seq and the first buffer in the
 > sk_receive_queue. In theory, the TCP stack makes sure that This Should
 > Never Happen (TM)... however, practice shows that there are still a few
 > bug reports from it out there (and one in my inbox).
 > 
 > Unfortunately, when it does happen for whatever reason, the situation
 > is not handled very well: the kernel logs a warning and breaks out of
 > the loop that walks the receive queue. It proceeds to find nothing else
 > to do on the socket and hits sk_wait_data, which cannot block because
 > the receive queue is not empty. As no data was read, the outer while
 > loop repeats (logging the same warning again) ad infinitum until the
 > system's syslog exhausts all available hard drive capacity.
 > 
 > This patch improves that behavior by going straight to a proper kernel
 > crash. The cause of the error can be identified right away and the
 > system's hard drive is not unnecessarily strained.
 > 
 > Signed-off-by: Julius Werner <jwerner@chromium.org>
 > ---
 >  net/ipv4/tcp.c |    2 +-
 >  1 files changed, 1 insertions(+), 1 deletions(-)
 > 
 > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
 > index 197c000..fcb0927 100644
 > --- a/net/ipv4/tcp.c
 > +++ b/net/ipv4/tcp.c
 > @@ -1628,7 +1628,7 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
 >  				 "recvmsg bug: copied %X seq %X rcvnxt %X fl %X\n",
 >  				 *seq, TCP_SKB_CB(skb)->seq, tp->rcv_nxt,
 >  				 flags))
 > -				break;
 > +				BUG();
 >  
 >  			offset = *seq - TCP_SKB_CB(skb)->seq;
 >  			if (tcp_hdr(skb)->syn)

We've had reports of this WARN against the Fedora kernel for a while.
Had this been immediately followed by a BUG(), we'd have never seen those traces at all,
and just got "my machine just locked up" reports instead.

The proper fix here is to find out why we're getting into this state.

	Dave

  reply	other threads:[~2012-11-07  1:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-07  0:15 [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crash Julius Werner
2012-11-07  1:39 ` Dave Jones [this message]
2012-11-07  1:51   ` Julius Werner
2012-11-07 15:54     ` Dave Jones
2012-11-07 16:29       ` [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crashusers Eric Dumazet
2012-11-07 16:43         ` Dave Jones
2012-11-07 17:05           ` Eric Dumazet
2012-11-07 17:15             ` Dave Jones
2012-11-07 19:32               ` Julius Werner
2012-11-07 19:33                 ` [PATCH] tcp: Avoid infinite loop on recvmsg bug Julius Werner
2012-11-07 19:40                   ` Eric Dumazet
2012-11-07 21:14                     ` Julius Werner
2012-11-07 23:33                       ` Eric Dumazet
2012-11-07 23:42                         ` Eric Dumazet
2012-11-08  2:25                           ` Julius Werner
2012-11-09  3:29                             ` Eric Dumazet
2012-12-10 19:33                               ` Julius Werner
2012-12-10 20:23                                 ` David Miller
2012-11-07  1:51   ` [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crash Eric Dumazet

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=20121107013907.GA31185@redhat.com \
    --to=davej@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@chromium.org \
    --cc=jmorris@namei.org \
    --cc=jwerner@chromium.org \
    --cc=kaber@trash.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msb@chromium.org \
    --cc=netdev@vger.kernel.org \
    --cc=snanda@chromium.org \
    --cc=yoshfuji@linux-ipv6.org \
    /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;
as well as URLs for NNTP newsgroup(s).