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

• Lines: 41
• Date: Thu Jul 26 13:29:45 2001
• Orig file: v2.4.7/linux/arch/i386/kernel/ldt.c
• Orig date: Wed Apr 11 19:05:37 2001

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);
 	}