patch-2.4.8 linux/arch/i386/kernel/ldt.c

Next file: linux/arch/i386/kernel/mpparse.c
Previous file: linux/arch/i386/kernel/dmi_scan.c
Back to the patch index
Back to the overall index

diff -u --recursive --new-file v2.4.7/linux/arch/i386/kernel/ldt.c linux/arch/i386/kernel/ldt.c
@@ -70,34 +70,19 @@
 	}
 
 	/*
-	 * Horrible dependencies! Try to get rid of this. This is wrong,
-	 * as it only reloads the ldt for the first process with this
-	 * mm. The implications are that you should really make sure that
-	 * you have a ldt before you do the first clone(), otherwise
-	 * you get strange behaviour (the kernel is safe, it's just user
-	 * space strangeness).
-	 *
-	 * we have two choices: either we preallocate the LDT descriptor
-	 * and can do a shared modify_ldt(), or we postallocate it and do
-	 * an smp message pass to update it. Currently we are a bit
-	 * un-nice to user-space and reload the LDT only on the next
-	 * schedule. (only an issue on SMP)
-	 *
 	 * the GDT index of the LDT is allocated dynamically, and is
 	 * limited by MAX_LDT_DESCRIPTORS.
 	 */
 	down_write(&mm->mmap_sem);
 	if (!mm->context.segments) {
+		void * segments = vmalloc(LDT_ENTRIES*LDT_ENTRY_SIZE);
 		error = -ENOMEM;
-		mm->context.segments = vmalloc(LDT_ENTRIES*LDT_ENTRY_SIZE);
-		if (!mm->context.segments)
+		if (!segments)
 			goto out_unlock;
-		memset(mm->context.segments, 0, LDT_ENTRIES*LDT_ENTRY_SIZE);
-		
-		/*
-		 * Possibly do an SMP cross-call to other CPUs to reload
-		 * their LDTs?
-		 */
+		memset(segments, 0, LDT_ENTRIES*LDT_ENTRY_SIZE);
+		wmb();
+		mm->context.segments = segments;
+		mm->context.cpuvalid = 1UL << smp_processor_id();
 		load_LDT(mm);
 	}
 

FUNET's LINUX-ADM group, linux-adm@nic.funet.fi
TCL-scripts by Sam Shen (who was at: slshen@lbl.gov)