linux-kernel - Re: Detailed Stack Information Patch [0/3]

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]

Message-ID: <20090122194126.GA5352@logfs.org>
Date:	Thu, 22 Jan 2009 20:41:26 +0100
From:	Jörn Engel <joern@...fs.org>
To:	Stefani Seibold <stefani@...bold.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Detailed Stack Information Patch [0/3]

On Tue, 20 January 2009 11:16:37 +0100, Stefani Seibold wrote:
> 
> this is a patch which give you a better overview of the userland
> application stack usage, especially for embedded linux.
> 
> Currently you are only able to dump the main process/thread stack usage
> which is showed in proc/pid/status by the "VmStk" Value. But you get no
> information about the consumed stack memory of the the threads.
>
> [...]
> 
> This patch is against 2.6.28.1. The patch is cpu independent, so it
> should work on all linux supported architectures, it was tested under
> x86 and powerpc. Also there is not dependency a library: glibc, uclibc
> and all other should work.
> 
> I hope you like it and want ask what is necessary for inclusion into the
> main stream kernel or linux-next? If you have ideas how to do things in
> a better way, please let me know.

First goal would be to get people interested.  Why would Joe
Kernelhacker care about this, what problem would it solve for him?  Next
goal is to prove to akpm that the solved problems are worth the
maintenance burden this code brings.

It would be nice to have diffstat added to each patch to give people
a quick overview.  More importantly, the number of #ifdef's in the
patches may raise a red flag.  You should try to remove them from common
code and have a single one in the headers:

#ifdef CONFIG_NEW_FEATURE

void handle_this(int foo, long bar);

#else

static inline void handle_this(int foo, long bar)
{
}
#endif

Not sure what else to say.  I'm still wondering whether it will solve a
problem for me.

Jörn

-- 
Joern's library part 4:
http://www.paulgraham.com/spam.html
--
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/