Description of problem:
There are two ways to get to the saved value for a CPU's GDT. One is through
cpu_gdt_table[cpu#], the other is through cpu_gdt_descr[cpu#].  The factors
that determine the contents of the two tables are:

   1. if you are the boot CPU (CPU0)
   2. if you are a PV xen guest
   3. if you are non-virtualized (HVM guest or running on a non-virtualized
      system).

For a boot CPU, or for any non-virtualized guest/system CPU,
cpu_gdt_descr[CPU#] points to cpu_gdt_table[CPU#] so it is OK to use either
data structure.

A PV guest's non-boot CPU's cpu_gdt_descr[CPU#] will point to a separately
allocated page which is set up correctly. Its cpu_gdt_table[CPU#] is not set
up so the entries are NULL.

These two factors lead to a bug in an MP 32-bit PV guest's general protection
fault (#GPF) handler.  A PV guest's non-boot CPU will not handle a user mode
#GPF because that code path references cpu_gdt_table[CPU#].  It will load NULLs
into the GDT and retry the faulting user instruction.  This leads to an endless
loop.

This patch changes the #GPF handler to use cpu_gdt_descr[] by way of
get_cpu_gdt_table() instead of cpu_gdt_table[].

--- linux-2.6.9/arch/i386/kernel/traps-xen.c.orig	2009-02-12 16:27:17.000000000 -0800
+++ linux-2.6.9/arch/i386/kernel/traps-xen.c	2009-02-12 16:26:01.000000000 -0800
@@ -622,7 +622,7 @@
 		set_user_cs(&current->mm->context.user_cs, limit);
 
 		desc1 = &current->mm->context.user_cs;
-		desc2 = cpu_gdt_table[cpu] + GDT_ENTRY_DEFAULT_USER_CS;
+		desc2 = &get_cpu_gdt_table(cpu)[GDT_ENTRY_DEFAULT_USER_CS];
 
 		/*
 		 * The CS was not in sync - reload it and retry the

Version-Release number of selected component (if applicable):
2.6.9-67, 2.6.9-78

How reproducible:



Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Oracle bug no 7916406.

Please include the above patch in el4.7 and el4.8 errata.