From: Jarek Poplawski <jarkao2@gmail.com>
To: Jay Cliburn <jacliburn@bellsouth.net>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Chris Snook <csnook@redhat.com>
Subject: Re: Need help debugging memory corruption
Date: Mon, 5 May 2008 07:27:34 +0000 [thread overview]
Message-ID: <20080505072734.GA4069@ff.dom.local> (raw)
In-Reply-To: <20080504145529.2eac672e@osprey.hogchain.net>
On Sun, May 04, 2008 at 02:55:29PM -0500, Jay Cliburn wrote:
> On Sun, 04 May 2008 16:55:08 +0200
> Jarek Poplawski <jarkao2@gmail.com> wrote:
>
> > Jarek Poplawski wrote, On 05/04/2008 04:24 PM:
> > ...
> >
> > > I'm definitely with less experience, so I wonder why it can't be
> > > a simple race between atl1_clean_rx_ring() and something (maybe even
> > > pending atl1_intr_rx()) on the other cpu writing skb while kfreeing?
> >
> >
> > Hmm... atl1_intr_rx() looks impossible, so atl1_alloc_rx_buffers()?
>
> I booted with nosmp and the bug is *much* harder to hit, but I still
> hit it once out of about 10 tries. Does the fact that I hit it once
> using nosmp disprove the race theory?
Probably not: I don't know how about preemption model, but especially
some maybe unkilled timers/watchdogs or workqueues could be considered.
Of course this idea looks very unprobable (should happen with less
than 4GB too), but should be quite easy to verify by adding some
temporary spinlocks around these rx ring operations?
Jarek P.
next prev parent reply other threads:[~2008-05-05 7:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-03 18:09 Need help debugging memory corruption Jay Cliburn
2008-05-04 14:24 ` Jarek Poplawski
2008-05-04 14:55 ` Jarek Poplawski
2008-05-04 19:55 ` Jay Cliburn
2008-05-05 7:27 ` Jarek Poplawski [this message]
2008-05-05 7:50 ` Jarek Poplawski
2008-05-04 15:02 ` Bart Van Assche
2008-05-04 19:52 ` Jay Cliburn
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=20080505072734.GA4069@ff.dom.local \
--to=jarkao2@gmail.com \
--cc=csnook@redhat.com \
--cc=jacliburn@bellsouth.net \
--cc=linux-kernel@vger.kernel.org \
--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).