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 Q6600@2.40GHz 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.
Created attachment 15270 [details] example reproducer
Reply-To: akpm@linux-foundation.org On Fri, 14 Mar 2008 18:48:15 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > 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: akpm@osdl.org > ReportedBy: kees@outflux.net > > > 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 Q6600@2.40GHz > 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. > There is a testcase in the bugzilla report.
Does the attached patch fix?
Created attachment 15283 [details] restore tss size after guest exit proposed fix
Yes, this appears to solve the behavior I was seeing. Thanks very much!
Fixed by 5dc832628229d2736fab10523566855c3cda622d in 2.6.25-rc7.