netdev - Re: [BUG 2.6.30-rc1] panic when loading oprofile

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 for Android: free password hash cracker in your pocket

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

Message-ID: <87fxf6pmh5.fsf@basil.nowhere.org>
Date:	Fri, 15 May 2009 14:41:26 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
Cc:	linux-kernel@...r.kernel.org, oprofile-list@...ts.sourceforge.net,
	netdev@...r.kernel.org, rusty@...tcorp.com.au
Subject: Re: [BUG 2.6.30-rc1] panic when loading oprofile

"Brandeburg, Jesse" <jesse.brandeburg@...el.com> writes:

Hi Jesse,

> when starting a profile run on the latest net-next kernel, I'm currently 
> trying to reproduce on 2.6.30-rc5 stock.

Were you able to reproduce it?

>
> config available upon request, arch=x86_64, recent (F10 or newer) oprofile 
> userspace.

it looks like two bugs: oprofile didn't catch a NMI that belongs to 
it (most likely) and the NMI watchdog referenced a NULL pointer
while processing an NMI.

Did you have the nmi watchdog enabled on the command line?

>
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<ffffffff8066080a>] nmi_watchdog_tick+0xa1/0x1d6

I don't get the same code as you. But the oopsing instruction in your
oops is

  2b:*  44 0f a3 28             bt     %r13d,(%rax)     <-- trapping instruction

with rax == 0 and I suspect it's one of the new cpu mask checks
I would try reverting

fcc5c4a2feea3886dc058498b28508b2731720d5
2f537a9f8e82f55c241b002c8cfbf34303b45ada
fcef8576d8a64fc603e719c97d423f9f6d4e0e8b

and see which one causes it. That would only fix the NMI watchdog bug
of course.

The oprofile not catching a event problem would be still open then.
I think the checks for overflowed counters are not 100% perfect
so that could happen. I have some patches in the works to use the new
global status register on arch perfmon 2, with that the overflow
check is somewhat more reliable. But that's more work.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html