linux-kernel - Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

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:	Thu, 21 Sep 2006 09:31:30 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Bill Huey <billh@...ppy.monkey.org>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <johnstul@...ibm.com>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	Dipankar Sarma <dipankar@...ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Esben Nielsen <simlo@...s.au.dk>
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Bill Huey <billh@...ppy.monkey.org> wrote:

> On Thu, Sep 21, 2006 at 09:22:16AM +0200, Ingo Molnar wrote:
> > * Bill Huey <billh@...ppy.monkey.org> wrote:
> > 
> > > Also, triggering a panic() at the beginning of the rt mutex acquire 
> > > was very useful since it made "in_atomic()" violations an explicit 
> > > error stopping the machine. Stack traces started to get really crazy 
> > > in this preemptive kernel with all sorts of things running unlike the 
> > > non-preemptive kernel and it was time consuming to figure out the real 
> > > stuff from the noise in the stack trace.
> > 
> > well you should absolutely have serial console if you effectively want 
> > to hack the Linux kernel. And in the serial console log you should 
> > search for stacktraces top-down, and concentrate on the first one - any 
> > subsequent one might be collateral damage of the first one.
> 
> Of course I did that. I'm not that stupid. :) The stack traces, even 
> with your above suggestions were too many and I had to break it down a 
> bug at a time, stack trace at a time, since I realize problems earlier 
> could clash and trigger other unrelated problems.
> 
> It was even problematic with the serial console on which is why I did 
> that. Maybe it was an artifact of having both the serial console and 
> video consoles on ?

perhaps the real problem was that you got 'intermixed' stackdumps from 
multiple CPUs crashing at once? Or was it simply the myriads of 
stackdumps? The myriads effect is easy to solve: only look at the first 
one, and fix them one by one :-)

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