Message-ID: <4518B4A0.6070509@goop.org>
Date:	Mon, 25 Sep 2006 22:03:28 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
CC:	Martin Bligh <mbligh@...gle.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	prasanna@...ibm.com, Andrew Morton <akpm@...l.org>,
	Ingo Molnar <mingo@...e.hu>, Paul Mundt <lethal@...ux-sh.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jes Sorensen <jes@....com>, Tom Zanussi <zanussi@...ibm.com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	Christoph Hellwig <hch@...radead.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	William Cohen <wcohen@...hat.com>, ltt-dev@...fik.org,
	systemtap@...rces.redhat.com, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Karim Yaghmour <karim@...rsys.com>,
	Pavel Machek <pavel@...e.cz>, Joe Perches <joe@...ches.com>,
	"Randy.Dunlap" <rdunlap@...otime.net>,
	"Jose R. Santos" <jrs@...ibm.com>
Subject: Re: [PATCH] Linux Kernel Markers 0.13 for 2.6.17

Mathieu Desnoyers wrote:
>> Mathieu Desnoyers wrote:
>>     
>>> To protect code from being preempted, the macros preempt_disable and
>>> preempt_enable must normally be used. Logically, this macro must make sure 
>>> gcc
>>> doesn't interleave preemptible code and non-preemptible code.
>>>  
>>>       
>> No, it only needs to prevent globally visible side-effects from being 
>> moved into/out of preemptable blocks.  In practice that means memory 
>> updates (including the implicit ones that calls to external functions 
>> are assumed to make).
>>
>>     
>>> Which makes me think that if I put barriers around my asm, call, asm trio, 
>>> no
>>> other code will be interleaved. Is it right ?
>>>  
>>>       
>> No global side effects, but code with local side effects could be moved 
>> around without changing the meaning of preempt.
>>
>> For example:
>>
>> 	int foo;
>> 	extern int global;
>>
>> 	foo = some_function();
>>
>> 	foo += 42;
>>
>> 	preempt_disable();
>> 	// stuff
>> 	preempt_enable();
>>
>> 	global = foo;
>> 	foo += other_thing();
>>
>> Assume here that some_function and other_function are extern, and so gcc 
>> has no insight into their behaviour and therefore conservatively assumes 
>> they have global side-effects.
>>
>> The memory barriers in preempt_disable/enable will prevent gcc from 
>> moving any of the function calls into the non-preemptable region. But 
>> because "foo" is local and isn't visible to any other code, there's no 
>> reason why the "foo += 42" couldn't move into the preempt region.  
>>     
>
> I am not sure about this last statement. The same reference :
> http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/gcc/Extended-Asm.html
>   
(This is pretty old, and this is an area which changes quite a lot.  You 
should refer to something more recent;
http://www.cims.nyu.edu/cgi-systems/info2html?/usr/local/info(gcc)Top 
for example, though in this case the quoted text looks the same.)

> I am just wondering how gcc can assume that I will not modify variables on the
> stack from within a function with a memory clobber. If I would like to do some
> nasty things in my assembly code, like accessing directly to a local variable by
> using an offset from the stack pointer, I would expect gcc not to relocate this
> local variable around my asm volatile memory clobbered statement, as it falls
> under the category "access memory in an unpredictable fashion".
>   

That not really what it means.  gcc is free to put local variables in 
memory or register, and unless you pass the local to your asm as a 
parameter, your code has no way of knowing how to find the current 
location of the local.  You could trash your stack frame from within the 
asm if you like, but I don't think gcc is under any obligation to behave 
in a deterministic way if you do.

"Unpredictable" in this case means that the memory modified isn't easily 
specified as a normal asm parameter.  For example, if you have an asm 
which does a memset(), the modified memory's size is a runtime variable 
rather than a compile-time constant.  Or perhaps your asm follows a 
linked list and modifies memory as it traverses the list.


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

Powered by blists - more mailing lists