> Looking at your strace output (I assume this is on an Intel?) clued me
> into a possible but in strncpy_from_user() in uaccess.h, simply
> because my fix works just fine on the Sparc...
>
> The core reads like this:
>
> __asm__ __volatile__( \
> " testl %1,%1\n" \
> " jz 2f\n" \
> "0: lodsb\n" \
> " stosb\n" \
> " testb %%al,%%al\n" \
> " jz 1f\n" \
> " decl %1\n" \
> " jnz 0b\n" \
> "1: subl %1,%0\n" \
> "2:\n" \
> ".section .fixup,\"ax\"\n" \
> "3: movl %2,%0\n" \
> " jmp 2b\n" \
> ".section __ex_table,\"a\"\n" \
> " .align 4\n" \
> " .long 0b,3b\n" \
> ".text" \
> : "=r"(res), "=r"(count) \
> : "i"(-EFAULT), "0"(count), "1"(count), "S"(src), "D"(dst) \
> : "si", "di", "ax", "memory")
>
> I belive the "subl %1,%0" is suspect, Linus any clues? It certainly
> looks incorrect to me because it is doing something like:
>
> old_count = count;
> new_count = strncpy(dst, src, count);
> return new_count - old_count;
>
> Which would return a negative number on success...
Hmm.. I would say that the last statement is rather
return old_count - new_count;
because %1 is new_count, %0 is old_count, and sub %1,%0 does %0=%0-%1.
Anyway, the strangest part is that the results seem to be
non-deterministic. It looks like %0 is sometimes set to 0, hence the
-58, -59 or so results (0 - (64 - 6)). Yet, there is no way %0 can ever be
0, it is set explicitely to 64 in the assembled code...
I played a little with this macro, adding redundant initializations (like
movl %1,%0 at the top) - it didn't make any difference. However, adding
a printk immediately after the macro, in strncpy_from_user, solves the
problem (and thrashes the logs :). Strange...
Ionut
--
Ionut Badulescu - Columbia College '98 E-mail:ib42@columbia.edu
Phone: (212)853-7875 Snail mail: 4A4 Wallach Hall
Fax: (212)695-5560 1116 Amsterdam Ave
PGP key available on request New York, NY 10027
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.