linux-kernel - Re: 4KSTACKS + DEBUG

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]

Date:	Wed, 28 May 2008 10:13:51 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Mike Snitzer <snitzer@...il.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jesper Juhl <jesper.juhl@...il.com>
Subject: Re: 4KSTACKS + DEBUG_STACKOVERFLOW harmful

Mike Snitzer wrote:

> Hi Eric,
> 
> Did you happen to get a patch together that reduces the stack usage of
> dump_stack?

Nope... but Andi Kleen sent a patch to put the warning on the irq stack
rather than the main process stack, so it avoids the original problem
with DEBUG_STACKOVERFLOW at least.

> Also, what did you use to print your (above) indented callchain stack
> usage of dump_stack?

That was just hand-edited... :)

> I'd like to be able to audit the worst case stack usage of _all_ call
> chains that originate from a given thread. This would effectively be
> like DEBUG_STACK_USAGE except with finer grained (per call-chain)
> statistics.  One crude way of doing this is to dump_stack() whenever a
> task's call-chain is the new "winner" as the biggest stack hog.

When will you test for the new winner?

> To do this safely it would seem to me that a leaner dump_stack() is needed...

It depends, I guess; if you have 8k stacks it'd probably fit ok in
almost all cases, I think.

> Lastly, would it be reasonable to utilize systemtap to implement what
> I described above?  I'm actually looking to debug 4KSTACKS as
> unobtrusively as possible so as to not alter the underlying kernel (in
> this case it happens to be a RHEL5 kernel but this could apply to any
> kernel).

I don't actually know if systemtap can do what you want (not saying it
can't; just saying I don't know...)

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