Re: vm86.c audit_syscall_exit() call trashes registers

From: Jeremy Fitzhardinge
Date: Sat Sep 29 2007 - 02:06:54 EST

William Cattey wrote:
> Your fix seems to have remedied a problem we are having with EDID
> fetches through vm86.c. At the present moment, we're trying to
> understand your cleanup so as to back port it to an earlier rev of the
> kernel (2.6.18).
> 3 questions for you:
> 1. Are we correct in understanding that your cleanup only touched
> vm86.c and vm86.h?
> 2. Do you remember your changes well enough from back when you made
> them in December 2006 to be able to point out the changes solely made
> to the audit calls?
> 3. Does correct operation of vm86.c in the 2.6 kernel require all of
> your changes, or just the subset that affects the audit calls?

It was only a small part of the patch. I think it was basically this
hunk (hand-edited, so this won't apply directly):

@@ -306,19 +334,18 @@ static void do_sys_vm86(struct kernel_vm
tsk->thread.screen_bitmap = info->screen_bitmap;
if (info->flags & VM86_SCREEN_BITMAP)
__asm__ __volatile__("xorl %eax,%eax; movl %eax,%fs; movl %eax,%gs\n\t");
- __asm__ __volatile__("movl %%eax, %0\n" :"=r"(eax));

/*call audit_syscall_exit since we do not exit via the normal paths */
if (unlikely(current->audit_context))
- audit_syscall_exit(AUDITSC_RESULT(eax), eax);
+ audit_syscall_exit(AUDITSC_RESULT(0), 0);

This is certainly a bogus piece of code, and it could result in more or
less random values of eax being passed to audit_syscall_exit(). But I
don't know if it will have any bearing on your EDID problem; the rest of
the patch is related to the introduction of using %gs as the base for
the per-processor data area, and shouldn't cause any functional change
to sys_vm86(), but its possible I fixed some other bug in the process.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at