linux-kernel - Re: [PATCH RFC 00/11] lock monitor: Separate features related to lock

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: <20100319125600.GA12211@Krystal>
Date:	Fri, 19 Mar 2010 08:56:00 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Hitoshi Mitake <mitake@....info.waseda.ac.jp>,
	Jason Baron <jbaron@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, h.mitake@...il.com,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [PATCH RFC 00/11] lock monitor: Separate features related to
	lock

* Frederic Weisbecker (fweisbec@...il.com) wrote:
> On Thu, Mar 18, 2010 at 10:40:42PM -0400, Mathieu Desnoyers wrote:
> > Well, the use-case that drove the asm goto implementation _is_ the tracepoints.
> > ;)
> > 
> > > 
> > > But, looking at __DO_TRACE:
> > > 
> > > 	if (it_func) {						\
> > > 		do {						\
> > > 			((void(*)(proto))(*it_func))(args);	\
> > > 		} while (*(++it_func));				\
> > > 	}
> > > 
> > > I would expect the compiler not to load the parameters in the stack
> > > before first checking the branch.
> > 
> > Note that you have to put that in its full context. It's a macro expanded within
> > a static inline function. The initial parameters are passed to the static
> > inline, not directly as "args" here. So parameters with side-effects have to be
> > evaluated before their result can be passed to the static inline function, so in
> > that sense their evaluation cannot be moved into the conditional branch.
> 
> 
> Evaluation yeah, I agree. A function passed as an argument is
> going to be evaluated indeed, or whatever thing that has a side effect.
> But there is nothing here that need to setup the parameters to the stack
> right before the true tracepoint call, not until we passed the branch check
> once.
> 
>  
> > > So, the fact that parameters are not loaded before we know we'll call
> > > the tracepoint is something we already have or is it something that the jump
> > > label brings in the package somehow?
> > 
> > It's standard compiler optimization behavior.
> 
> 
> Sure. My doubt is: currently with the upstream version, does the
> compiler tend to load the parameters to the stack before the branch is
> checked? Or is this a magic that jmp labels bring for whatever reason?

Even without the static jump patching, the compiler takes care of putting the
stack setup after the branch is checked. That worked with a standard test on a
variable, with immediate values and should still work with asm gotos.

I already did some presentations around these question. You can refer to my OLS
2008 slides, where I proposed static jump patching (ancestor of the asm gotos,
where I did the liveness analysis myself in the back of the compiler; good
enough for a prototype ;) ). Slide 11 discusses the branch vs stack setup
question:

http://lttng.org/files/slides/desnoyers-talk-ols2008.pdf

Even more in Sections 8.1, 8.2 and 8.3 of my thesis:

http://lttng.org/files/thesis/desnoyers-dissertation-2009-12-v27.pdf

8.1 Kernel Markers
8.2 Tracepoints
8.3 Immediate Values

Thanks,

Mathieu

> 
> Thanks.
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/