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

Relevant Pages