linux-kernel - Re: [PATCH] tracing: Add task activate/deactivate 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]

Message-ID: <1275323853.15884.14.camel@gandalf.stny.rr.com>
Date:	Mon, 31 May 2010 12:37:33 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tracing: Add task activate/deactivate tracepoints

Expect slow responses from me today. It's a US Holiday.


On Mon, 2010-05-31 at 18:18 +0200, Peter Zijlstra wrote:
> On Mon, 2010-05-31 at 16:48 +0200, Frederic Weisbecker wrote:
> > > Should we maybe cure this and rely on sched_switch() to detect sleeps?
> > > It seems natural since only the current task can go to sleep, its just
> > > that the whole preempt state gets a bit iffy.
> 
> How about something like the below?
> 
> Steve, is that proper usage of CREATE_TRACE_POINT?
> 
> ---
> Subject: sched, trace: Fix sched_switch() prev_state argument
> From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> Date: Mon May 31 18:13:25 CEST 2010
> 
> For CONFIG_PREEMPT=y kernels the sched_switch(.prev_state) argument
> isn't useful because we can get preempted with current->state !=
> TASK_RUNNING without actually getting removed from the runqueue.
> 
> Cure this by treating all preempted tasks as runnable from the
> tracer's point of view.
> 
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> ---
>  include/trace/events/sched.h |   19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6/include/trace/events/sched.h
> ===================================================================
> --- linux-2.6.orig/include/trace/events/sched.h
> +++ linux-2.6/include/trace/events/sched.h
> @@ -115,6 +115,23 @@ DEFINE_EVENT(sched_wakeup_template, sche
>  	     TP_PROTO(struct task_struct *p, int success),
>  	     TP_ARGS(p, success));
>  
> +#ifdef CREATE_TRACE_POINTS

I guess this could work. I can't think of anything that would cause this
to fail. But this is not exactly what the CREATE_TRACE_POINTS macro was
for.

Maybe we could make a CREATE_UTIL_FUNCTIONS macro that the
define_trace.h can unset like it does with CREATE_TRACE_POINTS before
recursively including the trace headers.

Maybe I'm a bit paranoid, but I'm a little nervous to extend the
CREATE_TRACE_POINTS macro to be used within the header to create utility
functions, although, currently I don't think there's anything
technically wrong in doing so.

-- Steve

> +static inline long __trace_sched_switch_state(struct task_struct *p)
> +{
> +	long state = p->state;
> +
> +#ifdef CONFIG_PREEMPT
> +	/*
> +	 * For all intents and purposes a preempted task is a running task.
> +	 */
> +	if (task_thread_info(p)->preempt_count & PREEMPT_ACTIVE)
> +		state = TASK_RUNNING;
> +#endif
> +
> +	return state;
> +}
> +#endif
> +
>  /*
>   * Tracepoint for task switches, performed by the scheduler:
>   */
> @@ -139,7 +156,7 @@ TRACE_EVENT(sched_switch,
>  		memcpy(__entry->next_comm, next->comm, TASK_COMM_LEN);
>  		__entry->prev_pid	= prev->pid;
>  		__entry->prev_prio	= prev->prio;
> -		__entry->prev_state	= prev->state;
> +		__entry->prev_state	= __trace_sched_switch_state(prev);
>  		memcpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
>  		__entry->next_pid	= next->pid;
>  		__entry->next_prio	= next->prio;
> 


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