linux-kernel - Re: request to add trace off and trace on with events

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: <1271740070.6381.41.camel@tropicana>
Date:	Tue, 20 Apr 2010 00:07:50 -0500
From:	Tom Zanussi <tzanussi@...il.com>
To:	rostedt@...dmis.org
Cc:	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Chase Douglas <chase.douglas@...onical.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: request to add trace off and trace on with events

On Mon, 2010-04-19 at 16:04 -0400, Steven Rostedt wrote:
> Hi Tom,
> 
> Could you add a way to do a call to tracing_on() or tracing_off() via
> the filters. I would like to do something like:
> 
> 
> echo 'if (pid == 1234) traceoff' > events/sched/sched_wakeup/filter
> 
> Where, if the sched_wakeup event is hit with pid == 1234 it will turn
> tracing off.
> 
> I would also like to do just:
> 
> echo 'traceoff' > events/sched/sched_wakeup/filter
> 
> to disable tracing every time the event is hit.
> 
> Perhaps you can just add a call back where the kernel could register
> something to be called if a command is used in the filter.
> 
> register_event_command("traceoff", trace_off_cb);
> 
> where the trace_off_cb is a function that is called by the event if the
> traceoff command is hit. This would allow other commands to be added
> later.
> 
> Would something like this be doable, I was looking at the code, and it
> certain looks feasible, but it would take me longer to implement it than
> it would you :-)
> 

If this was all you wanted to do, I think it would be pretty simple to
just pluck off the 'if' and the 'command' from the ends of the filter
string and hook it up to the command callback.

If neither of those were present and you just had a bare filter string,
it would invoke the 'default command' which would do just what it does
now - log it into the trace buffer.

Putting just the 'command' into the filter would also work - it would
always match and unconditionally invoke the command.

The 'if' syntax kind of limits it to a single command per filter though.
If you kept it as an expression e.g.

traceoff(pid == 1234)

or to make it more readable

traceoff_if(pid == 1234)

then you could maybe do things like nesting to fire multiple commands
per hit:

traceoff(logevent((pid == 1234))

That's seems like kind of a stretch, though, and implies chaining.  

Maybe something like:

traceoff,logevent if (pid == 1234)

would be more intuitive (or not).

Anyway, all of these would be pretty easily doable by simply
preprocessing the filter string.  Adding it properly to the parser would
be a little more work, and probably the way to go especially considering
that this wouldn't be the last feature that would be added ;-)

But I think Frederic's idea of decoupling the filters from the triggers
is probably better anyway, and it also allows for different triggers to
be associated with different filters, which the above can't do...

Tom

> Thanks,
> 
> -- 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/