linux-kernel - Re: [RFA][PATCH 0/4] tracing: Request for acks on fixing tracepoint code

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140226214342.6859d1f9@gandalf.local.home>
Date:	Wed, 26 Feb 2014 21:43:42 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [RFA][PATCH 0/4] tracing: Request for acks on fixing tracepoint
 code

On Thu, 27 Feb 2014 02:21:16 +0000 (UTC)
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:


> That is not the question. We don't care about how many times module.h is
> included in the kernel, but rather what module.h itself includes and could
> include in the future, throughout generic and arch-specific headers. If
> someone want to add a tracepoint in a static inline function located within
> a header file, they will need to include tracepoint.h. If tracepoint.h
> happens to have a circular dependency on this header, there comes include
> hell.

Actually, we've been telling people not to do that. That is, we don't
allow for tracepoints to be in headers anymore. We've removed all of
the offenders.

> 
> Arguing that it's OK to include headers within core instrumentation code
> because they are themselves included pretty much everywhere is a paved way
> to said include hell IMHO.

I find tracepoint.h far from a core instrumentation code. It's for
static tracepoints only. It's not like rcu or spinlock. It's about as
core as module.h is. I would argue that module.h is an even more core
header than tracepoint.h.


> > 
> > But as a compromise, I can move it to ftrace_event.h instead.
> 
> Since it will be used in tracepoint.c as well, which is a foundation of
> ftrace_event, it would be bad coupling to make tracepoint.c include
> ftrace_event.h (abstraction inversion). So I still think tracepoint.h
> is the right place to put this, only not with the module.h dependency.
> 
> But perhaps I'm missing something. Why is it so important to you to make
> this a static inline rather than a regular function call ?

As it is a one liner check, it just seemed to fit as a static inline.
As this isn't in any fast path, I guess I could make it a normal
function call.

Fine, I'll do that instead. Then the module header change can go into
linux-next instead of mainline/stable.

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