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 ;-)