On Sun, Jun 28, 2009 at 01:09:06AM +0900, Atsushi Nemoto wrote: > > The I-cache for page just being loaded is clean so no flushing needed. It > > is clean because when the page has been unmapped it was flushed or because > > the CPU switched to a fresh ASID. > > Then, flush_cache_range or flush_cache_page should be called then the > page was unmmapped, right? How about flush_cache_mm? It does not > flush icache currently. If that is being called then we're either about to terminate a process or to exec a new process. In either case flush_tlb_cache (on VIVT I-cache) will drop the tlb context which effectively is a full I-cache flush. > And how about kernel __init code pages? These pages are just freed on > free_initmem. Also how about code pages used by a module which is to > be unloaded from kernel? Init code pages won't be used to store code that will be executed at KSEG0 or XKPHYS addresses so I-cache coherency is not of interest. For modules the I-cache is being flushed on loading of the module, see calls to flush_icache_range() in kernel/module.c so I-cache coherency is not of concern on module unload. > > The reason for this bug is that when data is being shoveled around by the > > processor (as opposed to DMA) as on PIO block devices it'll end up sitting > > in the D-cache so I-cache refills will grab stale data from S-cache or > > memory. > > Yes, I suppose so on this swarm case, but I'm just thinking of other > case breaking icache coherency... Be careful with that - you might succeed ;-) Ralf
