Re: [patch] cache flush bug in mm/filemap.c (all kernels >= 2.5.30(atleast))

[Roman Zippel (zippel@linux-m68k.org)]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/