linux-kernel - Re: [RFC PATCH 1/2] tracing/stat: introduce new hashlist mode

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:	Mon, 01 Jun 2009 14:10:45 +0800
From:	Li Zefan <lizf@...fujitsu.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
CC:	LKML <linux-kernel@...r.kernel.org>,
	"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Zhaolei <zhaolei@...fujitsu.com>
Subject: Re: [RFC PATCH 1/2] tracing/stat: introduce new hashlist mode

Frederic Weisbecker wrote:
> Until now, the stat tracing was only able to gather the pointers
> to entries from a tracer, sort them and eventually pass these
> pointers to the tracer output handler.
> 
> It has two drawbacks:
> 
> - if the tracer concurrently releases a pointer, this one may be
>   dereference later in the output callback. There are ways to keep
>   track of these pointers but it ends up with extra code from the
>   tracers.
> 
> - the tracer has to handle its entries itself, through its own
>   hashlist, list or whatever.
> 

indeed

> This patch introduces a new mode for the stat tracers. Those can now
> ask the tracing stat Api to handle their entries, which includes the
> memory allocation, the access, the synchronization, the lookup, etc...
> 
> This is done through an internal hashlist that is built according
> to the number and size of entries provided by the tracer.
> 

But hashlist may not be suitable for all stat tracers?

> A tracer can choose between this new mode and the old one by using
> the HASH_NODES flag in struct tracer_stat.
> 

What's the advantages of the old mode towards this new mode?
I think it's better to move all existing stat tracers to
this new mode, and remove the old mode totally, if we want
this new mode.

> Instead of providing a pair of iterator callbacks, they just need
> to fill up the hlist_size and node_size fields.
> 
> Then using a unique id for each stat entries (usually a simple address
> to a traced thing), they can access to an entry using the two new pairs:
> 
> - get_stat_entry() which retrieve the entry and locks it against
>   concurrent updates
> - put_stat_entry() which unlocks the entry
> 
> Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>
> ---
>  kernel/trace/trace_stat.c |  329 ++++++++++++++++++++++++++++++++++++++++++++-
>  kernel/trace/trace_stat.h |   27 ++++-
>  2 files changed, 353 insertions(+), 3 deletions(-)
--
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/