Andi,
Sorry to have taken so long to take another step with this problem.
Once my customers had a work-around, other priorities crowded out
this
project. Today Chuck and I did a little more work. We'd heard
that a
more recent kernel alleged to fix this stuff. Doing some digging, we
came across this:
(http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20)
commit 49d26b6eaa8e970c8cf6e299e6ccba2474191bf5
Author: Jeremy Fitzhardinge <[email protected]>
Date: Thu Dec 7 02:14:03 2006 +0100
[PATCH] i386: Update sys_vm86 to cope with changed pt_regs and
%gs
usage
sys_vm86 uses a struct kernel_vm86_regs, which is identical to
pt_regs, but
adds an extra space for all the segment registers. Previously
this structure
was completely independent, so changes in pt_regs had to be
reflected in
kernel_vm86_regs. This changes just embeds pt_regs in
kernel_vm86_regs, and
makes the appropriate changes to vm86.c to deal with the new
naming.
Also, since %gs is dealt with differently in the kernel, this
change adjusts
vm86.c to reflect this.
While making these changes, I also cleaned up some frankly
bizarre
code which
was added when auditing was added to sys_vm86.
Signed-off-by: Jeremy Fitzhardinge <[email protected]>
Signed-off-by: Andi Kleen <[email protected]>
Cc: Chuck Ebbert <[email protected]>
Cc: Zachary Amsden <[email protected]>
Cc: Jan Beulich <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Jason Baron <[email protected]>
Cc: Chris Wright <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Chuck and I took a stab at extracting what we thought was the
relevant
change to the audit_syscall_exit code, but we must have gotten it
wrong. The EDID transfer always comes up zeros with our extract of
Fitzhardinge's patch.
At this point Chuck and I are trying to decide what will get us the
best testing with the least effort. (We keep planning to test with a
stock kernel, but last time that was on our TODO list, the project
languished for a month.)
Do you have a specific stock kernel revision to recommend we try on
our test system currently running Red Hat's 2.6.18? Are we right to
presume it would be 2.6.18-0 to demonstrate failure and 2.6.20.0 to
attempt to demonstrate success?
Are you the Andi Kleen who signed off on Fitzhardinge's patch, and if
so do you have some insight for Chuck and I about what pieces are
required to test and see if the bug really got fixed with his
cleanup?
I'd feel a lot more confident we were on the right track if I could
just correctly patch Fitzhardinge's cleanup into the test setup I
have
now.
-Bill
----
William Cattey
Linux Platform Coordinator
MIT Information Services & Technology
N42-040M, 617-253-0140, [email protected]
http://web.mit.edu/wdc/www/
On Aug 14, 2007, at 6:19 PM, Andi Kleen wrote:
On Tue, Aug 14, 2007 at 06:14:40PM -0400, William Cattey wrote:
In fact, I had begun the process of assuring myself that I could
indeed take a main line kernel, and install it in place of a Red
Hat
Kernel.
Should normally work. Sometimes there are incompatibilities
with udev -- it is safest to just compile in the drivers you
need to avoid that -- but likely it would work even without
that on a modern distro.
Shall I check back with you after we've re-run the test after
putting
the stock kernel on the machine? It will be a couple weeks because
they're moving my office on Thursday, I'm away on vacation the
following week, and I'm still unsure of the procedure to follow to
build a totally stock totally mainline kernel and put it into place
instead of what Red Hat has made.
Better report to the list again in case others want to chime in.
But you can put me into cc because I would need to merge
any resulting patch anyways.
-Andi
