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

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

Message-ID: <20060921072743.GB10337@gnuppy.monkey.org>
Date:	Thu, 21 Sep 2006 00:27:43 -0700
From:	Bill Huey (hui) <billh@...ppy.monkey.org>
To:	Ingo Molnar <mingo@...e.hu>
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>,
	"Bill Huey (hui)" <billh@...ppy.monkey.org>
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Thu, Sep 21, 2006 at 12:18:40AM -0700, Bill Huey wrote:
> On Thu, Sep 21, 2006 at 08:54:02AM +0200, Ingo Molnar wrote:
> > that you saw crashes under 2.6.17 - but did you manage to figure out 
> > what the reason is for those crashes, and do those reasons really 
> > necessiate the pushing of task-reapdown into yet another set of kernel 
> > threads?
> 
> Unfortunately no. I even used Robert's .config on my machine. I added a
> disk controller and networking device driver just to boot into his
> configuration and I still couldn't replicated any of his kjournald problems
> at all. If I had his hardware I'd have a better way of replicating those
> problems and pound it out.

Robert's stack traces looked completely wrong as well which is why I gave up.
Symbols showing up in this stack traces should have been completely compiled
out.

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.

It made the stack traces smaller and more immediately local to the problem
logic. Then I discovered panic() didn't work correctly in -rt so I fixed that
as well. There were a lot of little breakdowns in 2.6.17-rt...

bill

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