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: <20100319160041.GA2658@redhat.com>
Date:	Fri, 19 Mar 2010 12:00:41 -0400
From:	Jason Baron <jbaron@...hat.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	fweisbec@...il.com
Cc:	Hitoshi Mitake <mitake@....info.waseda.ac.jp>,
	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

On Fri, Mar 19, 2010 at 08:56:00AM -0400, Mathieu Desnoyers wrote:
> * 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.

right. stack setup happens after the branch is checked for asm gotos as
well. However, as mentioned functions as parameters, which have side-effects
need to be evaluated in the off case, there's nothing to be done about
that as its a correctness issue.

Hoever, constructs like a->b, do evaluated even in the disabled case.
This could be solved via macros, see my proposed patch set: 
http://marc.info/?l=linux-kernel&m=124276710606872&w=2

However, the conclusion of the thread was that this should be done in
the compiler, and as such I filed a bug with gcc about this issue.

I'll re-post an updated jump label series shortly.

thanks,

-Jason

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