On Mon, 29 Jun 2009 20:08:10 +0100, Ralf Baechle <firstname.lastname@example.org> wrote:
> > 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.
Thanks, I see. Then, how about VIPT I-cache case?
> > 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.
Same here. A physical page used to __init code might be reused for
user code page, so explicit flush (invalide) is required for VIPT