linux-kernel - RE: [PATCH]trace,x86: add x86 irq vector tracepoints

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: <alpine.LFD.2.02.1207131727430.32033@ionos>
Date:	Fri, 13 Jul 2012 17:48:37 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Seiji Aguchi <seiji.aguchi@....com>
cc:	Steven Rostedt <rostedt@...dmis.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"fweisbec@...il.com" <fweisbec@...il.com>,
	"'mingo@...e.hu' (mingo@...e.hu)" <mingo@...e.hu>,
	"vnagarnaik@...gle.com" <vnagarnaik@...gle.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"dle-develop@...ts.sourceforge.net" 
	<dle-develop@...ts.sourceforge.net>,
	Satoru Moriya <satoru.moriya@....com>
Subject: RE: [PATCH]trace,x86: add x86 irq vector tracepoints

On Fri, 13 Jul 2012, Seiji Aguchi wrote:
> Thomas,
> 
> Any comment?

Yes :)
 
> > > +DECLARE_EVENT_CLASS(irq_vector,
> > > +
> > > +	TP_PROTO(int irq),
> > > +
> > > +	TP_ARGS(irq),
> > > +
> > > +	TP_STRUCT__entry(
> > > +		__field(	int,	irq	)

Shouldn't this be vector?

> > > +DEFINE_EVENT(irq_vector, nmi_entry,
> > > +DEFINE_EVENT(irq_vector, nmi_exit,
> > > +DEFINE_EVENT(irq_vector, local_timer_entry,
> > > +DEFINE_EVENT(irq_vector, local_timer_exit,
> > > +DEFINE_EVENT(irq_vector, reschedule_entry,
> > > +DEFINE_EVENT(irq_vector, reschedule_exit,
> > > +DEFINE_EVENT(irq_vector, call_function_entry,
> > > +DEFINE_EVENT(irq_vector, call_function_exit,
> > > +DEFINE_EVENT(irq_vector, call_function_single_entry,
> > > +DEFINE_EVENT(irq_vector, call_function_single_exit,
> > > +DEFINE_EVENT(irq_vector, irq_work_entry,
> > > +DEFINE_EVENT(irq_vector, irq_work_exit,
> > > +DEFINE_EVENT(irq_vector, invalidate_tlb_entry,
> > > +DEFINE_EVENT(irq_vector, invalidate_tlb_exit,

So this set is pretty generic and applicable across
architectures. Good.

> > > +DEFINE_EVENT(irq_vector, error_apic_entry,
> > > +DEFINE_EVENT(irq_vector, error_apic_exit,
> > > +DEFINE_EVENT(irq_vector, thermal_apic_entry,
> > > +DEFINE_EVENT(irq_vector, thermal_apic_exit,
> > > +DEFINE_EVENT(irq_vector, threshold_apic_entry,
> > > +DEFINE_EVENT(irq_vector, threshold_apic_exit,
> > > +DEFINE_EVENT(irq_vector, spurious_apic_entry,
> > > +DEFINE_EVENT(irq_vector, spurious_apic_exit,
> > > +DEFINE_EVENT(irq_vector, x86_platform_ipi_entry,
> > > +DEFINE_EVENT(irq_vector, x86_platform_ipi_exit,

That part is x86 specific. If we go that route, we'll end up with
gazillions of arch specific vectors sooner than later.

Either we find better and more widely applicable names for them, if
there are similar functionalities on other architectures available, or
we should have a single generic tracepoint for those which cannot be
be mapped to anything useful shared across architectures.

Those x86 specific ones are not really frequently raised vectors, so
enabling them all won't affect performance and readability of the
traces too much.

Thanks,

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