Messages in this thread | | | Date | Wed, 05 Mar 2008 11:18:37 -0800 | From | Jeremy Fitzhardinge <> | Subject | Re: preempt bug in set_pmd_pfn? |
| |
Hugh Dickins wrote: > On Wed, 5 Mar 2008, Jeremy Fitzhardinge wrote: > >> If a thread goes from processor A -> B -> A, where A is first preempted >> between a pagetable update and a tlb flush, then the second time the thread >> runs on A may run with a stale tlb (if in the meantime A has either been idle >> or only running kernel threads). >> > > Right, thanks, because __flush_tlb_one opts out of the full active_mm > checking which goes on for userspace mms (which covers, for example, > the case of preemption before dup_mmap's flush_tlb_mm). > > But is there actually a case where there's a problem? So far as I can see, > set_pmd_pfn is there solely for discontig_32's __init remap_numa_kva; and > set_pte_pfn is there solely for set_fixmap, which operates on a per-cpu > area of pagetable, which would already be in bigger trouble if preemption > to another cpu were possible.
Yes, I meant set_pte_pfn; set_pmd_pfn is a typo.
Fixmap slots are global, not percpu; you may be thinking of kmap_atomic, which reserves percpu fixmap slots for its use. Most uses of set_fixmap are early in boot, where preemption (or other CPUs) isn't a factor. The exception is mapping the compat vdso global mapping. However, that is special-cased anyway, since the set_fixmap is followed by an explicit all-cpu tlb flush.
It seems to me that the correct fix is to just make __set_fixmap disable preemption for its duration; it probably doesn't make much difference for the native case, and it makes Xen happy.
J
| |