LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
To: Bill Fink <billfink@mindspring.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Guillaume Chazarain <guichaz@gmail.com>,
	Giangiacomo Mariotti <giangiacomo_mariotti@yahoo.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Netdev <netdev@vger.kernel.org>
Subject: Re: WARNING: at net/ipv4/tcp_input.c:2054 tcp_mark_head_lost()
Date: Fri, 29 Feb 2008 14:24:59 +0200 (EET)	[thread overview]
Message-ID: <Pine.LNX.4.64.0802290941120.18002@kivilampi-30.cs.helsinki.fi> (raw)
In-Reply-To: <20080228233514.63b7136e.billfink@mindspring.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2718 bytes --]

On Thu, 28 Feb 2008, Bill Fink wrote:

> On Thu, 28 Feb 2008, Andrew Morton wrote:
> 
> > On Thu, 28 Feb 2008 10:22:27 +0200 (EET) "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> wrote:
> > 
> > > [PATCH] TCP debug S+L (for 2.6.25-rcs, incompatible with 2.6.24.y)
> > > 
> > > ---
> > >  include/net/tcp.h     |    9 +++-
> > >  net/ipv4/tcp_input.c  |   18 +++++++-
> > >  net/ipv4/tcp_ipv4.c   |  127 +++++++++++++++++++++++++++++++++++++++++++++++++
> > >  net/ipv4/tcp_output.c |   23 +++++++--
> > 
> > I'll put this in -mm, see if we can flush anything out.

Ok, thanks. Were you aware of the considerable cpu consumption it will 
cause...? I.e., scanning throught the write queue in a number of place per 
ACK will certainly show up if somebody tests with netperf or so... ;-)
...Just please make sure it won't leak into mainline (for sure you would 
have done that without this explicit note :-)).

Good thing in that debug patch is that it catches inconsistencies 
immediately when they happen even if the cheap trap (which is in mainline) 
wouldn't ever see them because the situation would correct itself due to 
some other event.

> > Please let me know if/when it's obsolete, updated, etc.

Ok. Since many seem to now reporting this, I suppose the cause is 
relatively easy to find.

> > What is "S+L"?
> 
> I'll let Ilpo give the definitive answer.  But to test if I'm starting
> to grasp this, I'll give my understanding.  I believe 'S' means that a
> transmitted TCP skb has been acknowledged by a SACK, while 'L' means
> that a transmitted SKB is believed lost.  Since the 'S' state implies
> that the packet has actually been successfully received, it should not be
> possible for it to be considered lost ('L' state).  Thus an "S+L" state
> for a TCP skb is an internally inconsistent state and an indication of
> a TCP bug.
> 
> Anyone feel free to correct me if I'm way off base in my understanding.

Yes, this is exactly what it means. There's a big comment about them in 
the net/ipv4/tcp_input.c too. I answered to a similar question (but Bill 
mostly told all of it already):
  http://marc.info/?l=linux-netdev&m=120099888912383&w=2

We can do only cheap checking for sacked_out+lost_out > packets_out in 
mainline, and if that's true those warnings get printed but they won't 
necessarily tell the location of the bug because there might be 
considerable "latency" before that check triggers. On the other hand, this 
S+L debug patch verifies skb's ->sacked bitmaps against sacked/lost_out 
counters in multiple places per ACK and will catch the inconsistencies 
immediately at the site where they occurred (even if sacked_out + lost_out 
would still be below or equal to packets_out).



-- 
 i.

  reply	other threads:[~2008-02-29 12:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-21  4:04 Giangiacomo Mariotti
2008-02-23  8:03 ` Andrew Morton
2008-02-27  9:29   ` Ilpo Järvinen
2008-02-27 18:56     ` Guillaume Chazarain
2008-02-27 19:29       ` Ilpo Järvinen
2008-02-28  8:22         ` Ilpo Järvinen
2008-02-29  1:10           ` Andrew Morton
2008-02-29  4:35             ` Bill Fink
2008-02-29 12:24               ` Ilpo Järvinen [this message]
2008-03-02 12:20           ` Guillaume Chazarain
2008-03-02 12:38             ` Ilpo Järvinen
2008-03-02 13:15               ` Guillaume Chazarain
2008-03-02 19:51                 ` Ilpo Järvinen
2008-03-03  8:32                   ` Ilpo Järvinen
2008-03-03 13:40                     ` Ilpo Järvinen
2008-03-03 13:53                       ` [PATCH net-2.6] [TCP]: Must count fack_count also when skipping Ilpo Järvinen
2008-03-03 20:11                         ` David Miller
2008-03-24 20:36                         ` Frederik Himpe
2008-03-24 21:41                           ` David Miller
2008-03-25 21:24                             ` Ilpo Järvinen
2008-03-26  3:05                               ` 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=Pine.LNX.4.64.0802290941120.18002@kivilampi-30.cs.helsinki.fi \
    --to=ilpo.jarvinen@helsinki.fi \
    --cc=akpm@linux-foundation.org \
    --cc=billfink@mindspring.com \
    --cc=giangiacomo_mariotti@yahoo.com \
    --cc=guichaz@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --subject='Re: WARNING: at net/ipv4/tcp_input.c:2054 tcp_mark_head_lost()' \
    /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

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