note also that a lot of mem copies were already _not_ shielded with
clds, eg all copy_user() and friends.
> but all Linux entry and 'untrusted exit' points already do a 'cld', so the
> change would be safe, conceptually.
> future exit/entry points will have to do a 'cld' when returning from
> untrusted domains, just like they have to restore segment registers.
this should be explicitly documented somewhere in Documentation/
(it applies also to third party kernel code, ie modules).
> much of the remaining 284 cld's is still unjustified, because '*a = *b;'
> type of structure copies are inlined by GCC. (GCC generates a cld because
> user-space has to be prepared to be interrupted by uncooperative signal
> handlers and the like). So i added a cpy(x,y) macro which copies one
> structure into another via memcpy. We may not want to do it this way
> though, if it's too ugly. I have not found any way to prevent GCC from
> using it's own memcpy function in the structure copy case.
first, namespace polution, eg copy_struct() would be safer and less
conflict prone.
second, gcc seems to generate "better" code for the builtins than for
the inlined asms -- probably due to more optimal reg allocation (there's
room for improvement in string.h's routines; i played with that, but after
seeing incorrect code being generated (afaicr having two identical inputs
with only one of them marked as clobbered was the trigger) i gave up and
used the builtin). Note "better" doesn't necessarily == faster -- i didn't
benchmark them.
third, gcc unconditionally generating clds everywhere is a compiler
issue, which should be fixed in compiler land. something like
-mno-implicit-clds. (working around the problem by disabling gcc
optimizations isn't an optimal solution)
> the patch works just fine here, and i'm reasonably sure that no entry/exit
> point is missing. (i ran testcode for some time which does 'std' and 'cld'
> and thus tests the IRQ handler entry code and the syscall entry code. No
> problems whatsoever, as expected.)
as an additional datapoint - i didn't see any problems either, during
the last couple of months that i ran w/o (most of) the clds.
@@ -32,7 +32,6 @@
{
int d0, d1, d2;
__asm__ __volatile__(
- "cld\n"
"1:\tlodsb\n\t"
"stosb\n\t"
"testb %%al,%%al\n\t"
these changes are visible to userland; either your previous
/cld-ifdef-KERNEL approach/ or simply /#ifdef-KERNEL the whole header/
would probably be safer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/