From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Cc: "Ryan Hope" <rmh3093@gmail.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Performance Question: BUG_ON vs. WARN_ON_ONCE
Date: Mon, 14 Jul 2008 15:05:08 +1000 [thread overview]
Message-ID: <200807141505.08663.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <20080714073636.6c84be12@linux360.ro>
On Monday 14 July 2008 14:36, Eduard - Gabriel Munteanu wrote:
> On Mon, 14 Jul 2008 00:10:50 -0400
>
> "Ryan Hope" <rmh3093@gmail.com> wrote:
> > well the bug I recieved looked like it had to do with highmem and this
> > was the only code relating to mem that got touched, as for the other
> > person, their crash was reproducible and it definitely was an oops,
> > numlock led started to blink and system was unresponsive, for both of
> > us
> > reverting this change seems fix the issue, my dmesg log is attached to
> > this message
>
> There are a few things you should take into account before anything else:
> 1. The bug does not occur there, but in other code.
> 2. The kernel is tainted.
> 3. The oopses start occuring just after you load that tainted module,
> or at least something related (that drm stuff is linked to the radeon
> module, I presume, which is proprietary AFAIK)
>
> So you should retest after eliminating all these possible noise and
> error sources. Test both if your fix (revert) is correct and if it
> crashes without your fix.
>
> My guess is that would've happened sooner or later and your fix just
> moved stuff around enough to mask it. That static int from WARN_ON_ONCE
> means another 4 or 8 bytes in the kernel image, which might set things
> off in an already unstable environment.
Yeah, it looks like most or all of the errors cascade down from
the first one where a page gets freed while it is still in use and
mapped into page tables.
I'd say it is the driver mishandling the pages perhaps in its fault
function or the returned pages from a get_user_pages.
Probably best off reporting it to the drm driver authors first.
prev parent reply other threads:[~2008-07-14 5:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-13 23:57 Ryan Hope
2008-07-14 3:36 ` Eduard - Gabriel Munteanu
2008-07-14 4:10 ` Ryan Hope
2008-07-14 4:12 ` Ryan Hope
2008-07-14 4:36 ` Eduard - Gabriel Munteanu
2008-07-14 4:51 ` Ryan Hope
2008-07-14 5:05 ` Nick Piggin [this message]
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=200807141505.08663.nickpiggin@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=eduard.munteanu@linux360.ro \
--cc=linux-kernel@vger.kernel.org \
--cc=rmh3093@gmail.com \
/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
all inboxes | Powered by JetHome®