linux-kernel - Re: [PATCH 0/2] taskstats: uglify^Woptimize reply assembling

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: <45490402.1090706@watson.ibm.com>
Date:	Wed, 01 Nov 2006 15:30:58 -0500
From:	Shailabh Nagar <nagar@...son.ibm.com>
To:	Oleg Nesterov <oleg@...sign.ru>
CC:	Andrew Morton <akpm@...l.org>, Thomas Graf <tgraf@...g.ch>,
	Balbir Singh <balbir@...ibm.com>, Jay Lan <jlan@....com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] taskstats: uglify^Woptimize reply assembling

Oleg Nesterov wrote:
> The last series.
> 
Thanks again for the refactoring/review and optimizations to the code
base. Some of the earlier patches I'm still processing (to be sure the
timings etc. of signal clearing vs. task exit are right) but these later
ones are pretty straightforward and look good. Testing needed of course.

> Balbir, Shailabh, could you suggest me some user-space tests?

For stress testing, what we've used is to run

- one listener continuously getting exit stats (prototype listener
code in Documentation/accounting/getdelays.c)
- a multithreaded app where each thread does some disk I/O and some
cpu processing (incrementing a count etc.), threads get created and
destroyed in a continuous loop
- periodically query the multithreaded app above (print out its tgid first)
using another instance of Documentation/accounting/getdelays.c to see
if the delay data is getting incremented as expected by what the threads do.
- cerebrus and/or kernel compiles running in background just to create
a load

You can drop the cerebrus etc. if the load gets too much.

Running the above past a few hours has caught the kind of bugs seen so far.

> 
> Thomas, we are doing genlmsg_cancel() before nlmsg_free(), this is
> not necessary. Unless you have evil plans to complicate genetlink
> we can remove a little bit of code, what do you think?
> 
> Oleg.
> 

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