Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752113Ab2KGTkY (ORCPT ); Wed, 7 Nov 2012 14:40:24 -0500 Received: from mail-da0-f46.google.com ([209.85.210.46]:55779 "EHLO mail-da0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751475Ab2KGTkW (ORCPT ); Wed, 7 Nov 2012 14:40:22 -0500 Subject: Re: [PATCH] tcp: Avoid infinite loop on recvmsg bug From: Eric Dumazet To: Julius Werner Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Patrick McHardy , Hideaki YOSHIFUJI , James Morris , Alexey Kuznetsov , "David S. Miller" , Dave Jones , Sameer Nanda , Mandeep Singh Baines In-Reply-To: <1352316791-16491-1-git-send-email-jwerner@chromium.org> References: <1352316791-16491-1-git-send-email-jwerner@chromium.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 07 Nov 2012 11:40:19 -0800 Message-ID: <1352317219.5552.6.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2453 Lines: 66 On Wed, 2012-11-07 at 11:33 -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 addresses that issue by closing the socket outright and > throwing EBADFD to userspace (which seems most appropriate to me at this > point). As the underlying bug condition is "impossible" and therefore by > definition unrecoverable, this is the only sensible action other than a > full panic. > > Signed-off-by: Julius Werner > --- > net/ipv4/tcp.c | 7 ++++++- > 1 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c > index 197c000..d612308 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; > + goto selfdestruct; > > offset = *seq - TCP_SKB_CB(skb)->seq; > if (tcp_hdr(skb)->syn) > @@ -1936,6 +1936,11 @@ recv_urg: > recv_sndq: > err = tcp_peek_sndq(sk, msg, len); > goto out; > + > +selfdestruct: > + err = -EBADFD; > + tcp_done(sk); > + goto out; > } > EXPORT_SYMBOL(tcp_recvmsg); > What I find very sad in all this is that you didnt mention the driver that was triggering this bug. So instead of making real progress, we are discussing of some dubious 'fixes' -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/