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

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

Message-ID: <20090601163149.GA5988@nowhere>
Date:	Mon, 1 Jun 2009 18:31:50 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Li Zefan <lizf@...fujitsu.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

On Mon, Jun 01, 2009 at 02:10:45PM +0800, Li Zefan wrote:
> 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?


Almost all of them.
More explanations below.


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



As an example the old mode should be kept for branch tracing
because it uses static variables access, which is totally
immediate access, necessary to trace each "if" :-)

There, the stat tracer only services the sorting feature.

But for most other stat tracers, the new hashlist is more suitable
instead of having multiple versions of hashlist or list...
So yes, the others should be converted to use this new mode.

Thanks.

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