From: Russell King <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
