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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |