linux-kernel - Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set via debugfs

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: <y0mr469e9t0.fsf@fche.csb>
Date:	Mon, 10 Mar 2014 22:41:31 -0400
From:	fche@...hat.com (Frank Ch. Eigler)
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Berg <johannes.berg@...el.com>
Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set via debugfs


Hi -


>> From: Steven Rostedt <rostedt@...dmis.org>
>> 
>> Tracepoints were made to allow enabling a tracepoint in a module before that
>> module was loaded. When a tracepoint is enabled and it does not exist, the
>> name is stored and will be enabled when the tracepoint is created.
>> 
>> The problem with this approach is that when a tracepoint is enabled when
>> it expects to be there, it gives no warning that it does not exist.

So it is a deferred-activation kind of call, with no way of knowing
when or if the tracepoints will start coming in.  Why is that
supported at all, considering that clients could monitor modules
coming & going via the module_notifier chain, and update registration
at that time?


>> +	entry = get_tracepoint(name);
>> +	/* Make sure the entry was enabled */
>> +	if (!entry || !entry->enabled)
>> +		ret = -ENODEV;

For what it's worth, I agree with Mathieu that this sort of successful
failure result code is a problem for tracking what needs cleanup and
what doesn't.  (In systemtap's case, if this change gets merged, we'll
have to treat -ENODEV as if it were 0.)


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