linux-kernel - Re: [3.4-rc3] Thread overran stack, or stack corrupted

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Apr 2012 13:14:38 -0400
From:	Dave Jones <davej@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [3.4-rc3] Thread overran stack, or stack corrupted

On Wed, Apr 18, 2012 at 10:02:06AM -0700, Linus Torvalds wrote:

 > > the traces below, which look pretty.. deep.
 > 
 > Yeah. Sadly, they are less useful than I was hoping for. It's not some
 > single deep call-chain, it's almost all debug stuff and the "did we
 > release the RCU lock" or preemption checks, which I guess makes sense.
 > You have tons of options enabled in your kernel that makes for deeper
 > stack traces, and then all the interesting stuff gets overwritten by
 > what happened later.

One thing I'm curious about.. Some of the function names are repeated
for a reason that doesn't seem obvious to me, when the call chain doesn't
call them in a loop. What's that about ?

 > I assume you have USB serial console on for a reason (ie: great for
 > catching oopses before the machine dies), but in this case it hurts.

Yeah, there's a (possibly related) problem where once a day some oops
gets triggered that just wedges the machine. I've not managed to capture
it yet, and the most I've gotten over the usb console was about
a dozen characters before it hung.

I've disabled the console blanking, and hooked up a monitor to it.
Perhaps that'll be enough to capture it without resorting to usb console.

 > Could you try just adding a
 > 
 >    console_lock();
 >    ...
 >    console_unlock();
 > 
 > around the show_trace() call. That will force the code to not actually
 > call down to the console layer until after the console_unlock(), so
 > the printing of the stack trace won't affect the stack *too* much.

That's a neat trick. I'll add that, in case I do have to fall back to usb console.

thanks,

	Dave

--
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/