linux-kernel - Re: [PATCH] tracing/profile: Fix profile_disable vs module

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: <20090825103907.GB28287@elte.hu>
Date:	Tue, 25 Aug 2009 12:39:07 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Li Zefan <lizf@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tracing/profile: Fix profile_disable vs module_unload


* Peter Zijlstra <peterz@...radead.org> wrote:

> On Tue, 2009-08-25 at 12:22 +0200, Ingo Molnar wrote:
> > * Peter Zijlstra <peterz@...radead.org> wrote:
> > 
> > > On Tue, 2009-08-25 at 11:05 +0200, Ingo Molnar wrote:
> > > > * Peter Zijlstra <peterz@...radead.org> wrote:
> > > > 
> > > > > Ah, my bad, I was thikning tracepoint_probe_register() was the 
> > > > > thing that registered the tracepoint itself, not the callback.
> > > > > 
> > > > > Ok, then what's the problem?, don't do modules that consume their 
> > > > > own tracepoints, seems simple enough.
> > > > 
> > > > is this a reasonable restriction? I dont see any reason why the 
> > > > act of defining and providing a tracepoint should be exclusive 
> > > > of the ability to make use of it.
> > > 
> > > It doesn't make sense to me, you don't need your own tracepoints 
> > > because you generate the events yourself, you already have them.
> > 
> > For a reasonable large subsystem/driver i can very well imagine 
> > this to happen: why should the subsystem add _another_ layer of 
> > callbacks if it can reuse the generic tracepoint code and 
> > register itself to those?
> 
> Then that subsystem would be non functioning when the kernel is 
> build without tracepoints.

... except if it selects all required core kernel functionality it 
relies on? Tracepoints and typed callbacks really go hand in hand 
and it would be nice to see some more synergy in that space. 
(instead of crappy, prioritized notifier chains for example.)

> Nothing should rely on tracepoint being present, they are and 
> should remain a debug feature, not a core hook thing.
> 
> Do you really wish to burden every tracepoint user with the extra 
> logic needed to deal with modules?

Not necessarily - i'm just outlining why i think that the 'dont 
allow subsystems to utilize tracepoint callbacks' is a restriction 
we should not live with voluntarily.

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