New: "in" after successful ioperm() results in SEGV after kvm use

http://bugzilla.kernel.org/show_bug.cgi?id=10246

Summary: "in" after successful ioperm() results in SEGV after kvm
use
Product: Memory Management
Version: 2.5
KernelVersion: 2.6.25-rc5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]

Latest working kernel version: N/A
Earliest failing kernel version: 2.6.24
Distribution: Ubuntu, but tested with mainline
Hardware Environment: intel mobo, Intel(R) Core(TM)2 Quad CPU [email protected] Software Environment: kvm 62 (x86_64)
Problem Description:

After a successful ioperm() call, otherwise valid "in" instructions will segv if a kvm VM has started.

Steps to reproduce:

1) run attached reproducer prior to starting a kvm VM, results are:

# ./ioperm
getting 0x3b4-0x3df permission...
fetching 0x3cc...
ok: 1

2) start a kvm VM (bug exists only after actually starting a guest VM)

3) run reproducer, which now fails:

# ./ioperm
getting 0x3b4-0x3df permission...
fetching 0x3cc...
Segmentation fault (core dumped)

Note that it does not always fail. Running within gdb seems to reduce the chances that it will fail. But when it does, it is clearly the "in" that is failing:

Program received signal SIGSEGV, Segmentation fault. 0x00000000004006e4 in inb ()
(gdb) x/1i $pc
0x4006e4 <inb+12>: in (%dx),%al
(gdb) info reg rdx
rdx 0x3cc 972

I have had the sense that running the CPUs at full load (niced) increases the chance for failure.