Messages in this thread | | | Date | Tue, 04 Mar 2008 13:13:43 -0800 | From | Jeremy Fitzhardinge <> | Subject | preempt bug in set_pmd_pfn? |
| |
I think set_pmd_pfn, which is only called by __set_fixmap, might have a preempt bug in it.
It can be executed with preemption enabled, but what if it gets preempted
set_pmd(pmd, pfn_pmd(pfn, flags)); /* * It's enough to flush this one mapping. * (PGE mappings get flushed as well) */ >here< __flush_tlb_one(vaddr); }
?
Won't this leave a stale tlb on the old processor?
I noticed this because the Xen tlb flushing code effectively has a smp_processor_id(), which provokes a warning when preemption is enabled. It seems to me that it never makes sense to be doing a tlb flush unless you know which processor you're actually running on...
J
| |