Messages in this thread | | | Date | Sat, 30 Jul 2005 12:40:52 -0700 (PDT) | Subject | Re: 2.6.13-rc3: cache flush missing from somewhere | From | "David S. Miller" <> |
| |
From: Russell King <rmk+lkml@arm.linux.org.uk> Date: Fri, 29 Jul 2005 16:13:43 +0100
> My current patch to get this working is below. The only thing which > really seems to fix the issue is the __flush_dcache_page call in > read_pages() - if I remove this, I get spurious segfaults and illegal > instruction faults.
If one cpu stores, does it get picked up in the other cpu's I-cache? If not, you cannot use the lazy dcache flushing method, and in fact you must broadcast the flush on all processors.
> If I make flush_dcache_page() non-lazy, this also fixes it, but this > is not desirable. The problem also goes away if I disable the write > allocate cache mode.
Strange.
> If I call __flush_dcache_page() from update_mmu_cache() (iow, always > ensure that we have I/D coherency when the page is mapped into user > space) the effect is the same - I see random faults.
You have to do the flush on the processor that does the store, at a minimum. But if other cpus have no way to "notice" stores on other cpus in their I-cache, this alone is not sufficient.
Based upon your report, I strongly suspect that remote I-caches do not see cpu local stores when the cache is in write allocate mode. If this is true, it's a horrible design decision for an SMP system :(
> To me, it feels like there's a path which results in pages mapped into > user space without update_mmu_cache() being called, but I'm unable to > find it. Ideas?
Ptrace can make this occur, but that's obviously not what you're seeing here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |