Messages in this thread | | | Date | Thu, 29 May 2003 02:12:47 +0200 (CEST) | From | Roman Zippel <> | Subject | Re: [patch] cache flush bug in mm/filemap.c (all kernels >= 2.5.30(at least)) |
| |
Hi,
On Wed, 28 May 2003, David S. Miller wrote:
> set_pte() establishes the mapping, this means another cpu can get the pte > and start reading the data e.g. into the instruction cache, but if that > cpu still has dirty data in the data cache (e.g. a write() or a disk > read), the following update_mmu_cache() might be too late. > > If that really matters for you, your set_pte() could add this > operation to a list of pending set_pte()'s in the mm_struct arch > specific context area. Then at update_mmu_cache() it runs this > list of todo items. > > I don't see the problem.
This would require quite some magic in set_pte(), as update_mmu_cache() is not always called after set_pte(). I'd prefer to keep flush_icache_page() for this, there are only a few places, which require this and it doesn't hurt to keep this explicit. BTW it's a bit unfortunate that flush_dcache_page() is called for reads and writes. This might be needed for virtual indexed caches, but for icache/dcache synchronization I'm only interested in writes (so that write()/exec() works, but not every read() causes a cache flush). Could we split that interface?
bye, Roman
- 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/
| |