From: Andrew Morton <akpm@linux-foundation.org>
To: David Miller <davem@davemloft.net>
Cc: ilpo.jarvinen@helsinki.fi, netdev@vger.kernel.org
Subject: Re: tcp crash in net-2.6 tree
Date: Fri, 30 Mar 2007 15:06:03 -0700 [thread overview]
Message-ID: <20070330150603.edeb2023.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070330.144347.68157619.davem@davemloft.net>
On Fri, 30 Mar 2007 14:43:47 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: "Ilpo_J__rvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Fri, 30 Mar 2007 17:33:28 +0300 (EEST)
>
> > If there is nothing at high_seq (application hasn't given any data to/past
> > that point), the search fails to find any skb and returns NULL... But I
> > have no idea how this can happen? As TCP does after(skb->seq,
> > tp->high_seq) (even in the quoted code block) guaranteeing that something
> > is there after the high_seq for TCP to step temporarily on... So at least
> > one skb should have it's end_seq after tp->high_seq (actually there
> > should be at least two valid skbs after tp->high_seq since the used
> > sequence number space does not have holes), which should be enough to get
> > an existing skb from write_queue_find?!
> >
> > I also checked all call paths to tcp_update_scoreboard_fack to make sure
> > that snd_una hasn't gone past high_seq and found nothing suspicious (and
> > that wouldn't return NULL anyway I think)...
>
> Let's not speculate, let's find out for sure if snd_una is
> surpassing high_seq while we're in this state.
>
> Andrew please give this debugging patch a spin,
OK, will take a look at that this evening, hopefully.
> and also what
> is your workload? I'd like to play with it too.
I use an x86_64 box as a distcc server: shove .i fiels at it, get .o files
sent back. I was using it thusly and noticed that it had died.
Also, an x86_64 box I have here at google was hanging yesterday and that
appears to have stopped since I removed a couple of x86_64 patches and
git-net. I'm in the process of working out what fixed it...
> I've tried to code this patch so that if the bug triggers your
> machine shouldn't crash and burn completely, just spit out the
> log message.
ok.. I don't know how repeatable the distcc crash is. We'll see.
distccd seems to be rather good at triggering networking problems - I think
that's the third one I've seen in the past few years.
next prev parent reply other threads:[~2007-03-30 22:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-30 6:09 tcp crash in net-2.6 tree Andrew Morton
2007-03-30 14:33 ` Ilpo Järvinen
2007-03-30 16:18 ` Andrew Morton
2007-03-30 21:43 ` David Miller
2007-03-30 22:06 ` Andrew Morton [this message]
2007-03-30 22:12 ` David Miller
2007-03-30 22:10 ` Thomas Graf
2007-03-30 22:15 ` David Miller
2007-03-31 10:19 ` ijjarvin
2007-04-02 8:38 ` Ilpo Järvinen
2007-04-02 9:02 ` David Miller
2007-04-02 21:06 ` Thomas Graf
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=20070330150603.edeb2023.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=netdev@vger.kernel.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).