Re: 2.6.13-rc3: cache flush missing from somewhere

["David S. Miller" <davem@davemloft.net>]

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/