linux-kernel - Re: [PATCH] tracing/function-return-tracer: don't trace kfree while it frees the return stack

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: <alpine.DEB.1.10.0811231237470.13888@gandalf.stny.rr.com>
Date:	Sun, 23 Nov 2008 14:24:42 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tracing/function-return-tracer: don't trace kfree while
 it frees the return stack

On Sun, 23 Nov 2008, Ingo Molnar wrote:
> > 
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index 90d99fb..ffff7ec 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -1628,8 +1628,9 @@ void ftrace_retfunc_init_task(struct task_struct *t)
> >  
> >  void ftrace_retfunc_exit_task(struct task_struct *t)
> >  {
> > -	kfree(t->ret_stack);
> > +	struct ftrace_ret_stack	*ret_stack = t->ret_stack;
> >  	t->ret_stack = NULL;
> > +	kfree(ret_stack);
> 
> heh, nice one :)
> 
> note that we also need to keep gcc from reordering things here (no 
> matter how unlikely in this particular case).

I first thought that too, but thinking about it, if gcc does do that, then
it will break the logic for a correct C program.

t is passed in as a pointer, then it modifies the contents of t (which 
could be a global pointer), then it calls a external function, that might 
also reference the global pointer.

This means that if it were to reorder the two, it would break C, because 
the compiler can not assume that the called function will read the global 
pointer either.

In other words, the compiler should not need to worry about SMP or 
modifications done by interrupts or other threads. But the compiler should 
always preserve the order that is assumed by a single context.

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