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)
mark_screen_rdonly(tsk->mm);
__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.
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/
