Re: [PATCH] Linux Kernel Markers 0.13 for 2.6.17

[Jeremy Fitzhardinge]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/