linux-kernel - Re: Performance Question: BUG_ON vs. WARN_ON

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200807141505.08663.nickpiggin@yahoo.com.au>
Date:	Mon, 14 Jul 2008 15:05:08 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
Cc:	"Ryan Hope" <rmh3093@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Performance Question: BUG_ON vs. WARN_ON_ONCE

On Monday 14 July 2008 14:36, Eduard - Gabriel Munteanu wrote:
> On Mon, 14 Jul 2008 00:10:50 -0400
>
> "Ryan Hope" <rmh3093@...il.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/