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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
