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) */__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 --
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Andrew Morton | -mm merge plans for 2.6.23 |
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| PJ Waskiewicz | [ANNOUNCE] ixgbe: Data Center Bridging (DCB) support for ixgbe |
| David Miller | Re: [GIT]: Networking |
