lkml.org 
[lkml]   [2003]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.106 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site