linux-kernel - Re: [PATCH 2/2] perf lock: Fix output of tracing lock events

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:	Thu, 17 Dec 2009 10:24:45 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Hitoshi Mitake <mitake@....info.waseda.ac.jp>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org,
	Paul Mackerras <paulus@...ba.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 2/2] perf lock: Fix output of tracing lock events

On Wed, 2009-12-16 at 12:28 +0900, Hitoshi Mitake wrote:
> This patch adds address of lockdep_map to each lock events.
> perf lock uses these addresses as IDs of lock instances.
> 
> And this removes waittime from output of lock_acquired event.
> The value will be caliculated in userspace based on timestamp.
> 
> Signed-off-by: Hitoshi Mitake <mitake@....info.waseda.ac.jp>
> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> Cc: Paul Mackerras <paulus@...ba.org>
> Cc: Frederic Weisbecker <fweisbec@...il.com>
> ---
>  include/trace/events/lock.h |   27 ++++++++++++++++++---------
>  kernel/lockdep.c            |    2 +-
>  2 files changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/include/trace/events/lock.h b/include/trace/events/lock.h
> index a870ba1..2f94e25 100644
> --- a/include/trace/events/lock.h
> +++ b/include/trace/events/lock.h
> @@ -18,16 +18,19 @@ TRACE_EVENT(lock_acquire,
>  	TP_ARGS(lock, subclass, trylock, read, check, next_lock, ip),
>  
>  	TP_STRUCT__entry(
> +		__field(struct lockdep_map *, lockdep_addr)
>  		__field(unsigned int, flags)
>  		__string(name, lock->name)
>  	),

I feel a bit awkward explicitly leaking kernel pointers like that. All
this is accessible by root only (for now) so its not too harmfull, but
sitll.

Also, I don't think we want to expose the struct lockdep_map thing, a
regular void * would be better.

As to removing the waittime, I'm not sure, in this case, yes, but if you
want some other processing that hooks straight into the tracepoints
instead of using a logging structure, it might be useful.

Removing that do_div() from there and exposing waittime as u64 in nsec,
for sure, that do_div() is just silly.

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