2.6.12-rc5-mm1 includes Andrea's seccomp-disable-tsc patch,
which I believe is broken on SMP. In process.c we find:
/*
+ * This function selects if the context switch from prev to next
+ * has to tweak the TSC disable bit in the cr4.
+ */
+static void disable_tsc(struct thread_info *prev,
+ struct thread_info *next)
+{
+ if (unlikely(has_secure_computing(prev) ||
+ has_secure_computing(next))) {
+ /* slow path here */
+ if (has_secure_computing(prev) &&
+ !has_secure_computing(next)) {
+ clear_in_cr4(X86_CR4_TSD);
+ } else if (!has_secure_computing(prev) &&
+ has_secure_computing(next))
+ set_in_cr4(X86_CR4_TSD);
+ }
+}
which it calls from __switch_to().
The problem is that {set,clear}_in_cr4() both update a single
global mmu_cr4_features variable, which is asynchronously written
to all CPUs by {,__}flush_tlb_all(). Hence, the CR4.TSD setting
is at best probabilistic.
I spotted this because perfctr used to flip CR4.PCE in __switch_to()
ages ago, but I had to abandon that when kernel 2.3.40 changed to
the current scheme with a global mmu_cr4_features.
(Another reason was that CR4 writes were and still are very slow.)
/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]