linux-kernel - Re: [PATCH v2] trace: Add x86 irq vector entry/exit 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]

Date:	Thu, 7 Jul 2011 02:25:15 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	David Sharp <dhsharp@...gle.com>,
	Vaibhav Nagarnaik <vnagarnaik@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Michael Rubin <mrubin@...gle.com>, x86@...nel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jiaying Zhang <jiayingz@...gle.com>
Subject: Re: [PATCH v2] trace: Add x86 irq vector entry/exit tracepoints

On Wed, Jul 06, 2011 at 05:02:31PM -0700, H. Peter Anvin wrote:
> On 07/06/2011 04:56 PM, Frederic Weisbecker wrote:
> > And even if tracepoints are not supposed to be stable ABI (I actually believe there
> > is no absolute answer to that, it depends on the tracepoint and on the context),
> > tools are much happier with a common tracepoint interface amongst archs.
> 
> What you're suggesting here is an ad hoc ABI.  This is insanely
> irresponsible -- ABIs need to be designed, not randomly appeared.

I'm suggesting two things:

1) If every arch implement a tracepoint for a generic event, then move the tracepoint
to the generic code. I believe that part is not very controversial.

2) If every arch implement a common event that is not implemented in core code (I believe
it was the case for reschedule_interrupt few times ago but changed lately) then try
to have a common tracepoint for every archs if possible. So that we don't have
thousand names for the same event, or different parameters name when those parameters and the
event semantic are exactly the same amongst every architecture.

Trace events are irresponsible anyway because they involve that "ABI not really stable but tools
rely on it so...well...)". I'm not sure the above points make the situation worse though. Probably
the cases that fit in 2) need to be carefully checked to ensure they really fit in 2).

Having each archs proposing their own wild tracepoints is not going to cure the fundamental
nature of trace events. An arch that implements its own tracepoint already applies a new ad-hoc
ABI. Its scope is just smaller.
--
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/