linux-kernel - Re: systemtap broken by removal of register_timer

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:	Tue, 30 Apr 2013 02:19:00 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Mel Gorman <mgorman@...e.de>, Ingo Molnar <mingo@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	SystemTap <systemtap@...rceware.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: systemtap broken by removal of register_timer_hook

On Fri, Apr 19, 2013 at 10:46:55AM -0400, Frank Ch. Eigler wrote:
> Hi, Frederic -
> 
> 
> > > How about this?
> > >
> > > Author: Frank Ch. Eigler <fche@...hat.com>
> > > Date:   Wed Apr 3 10:35:21 2013 -0400
> > >
> > >     profiling: add profile_tick tracepoint
> > > [...]
> 
> > It would be better not to tie this to CONFIG_PROFILING.
> > A tracepoint in update_process_times() instead would be great but it's
> > sometimes called several times in a tick from some archs.
> > Probably we need something like:
> > 
> > static inline tick_trace(struct pt_regs *regs)
> > {
> >     trace_timer_tick(regs);
> >     profile_tick(CPU_PROFILING);
> > }
> 
> I looked into this, but found no natural place to define such an
> inline function from which to call into a tracepoint, without having
> to #include the <event/FOO.h> file many times.

You could include it from linux/profile.h or linux/tick.h and
define profile_tick to "{ trace_tick(); __profile_tick()}" .

But in a second thought, using a tracepoint in a general purpose header
resulted in bad circular headers dependency in the past, we had bitter
experiences with trace_softirq_raise for example.

> Nor does it seem
> appropriate to do the identical #define CREATE_TRACE_POINTSw part from
> all the different arch/.../*.c files that may call into that inline.
>
> If you'd like to stick to this idea, please advise further where you
> think the tracepoint definition & declarations should go.
> 
> In the alternative, here is v2 of the patch, just changing the
> tracepoint-printing argument as suggested by jistone.

But your tracepoint still depends on CONFIG_PROFILING and I would
really like to avoid that.

How about creating trace_tick() in include/trace/events/timer.h
and call it from tick_periodic() and tick_sched_handle().

This only leaves the archs that don't support generic clockevents
behind. This should be no big deal, they can integrate this tracepoint
later if they need to.

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