On Mon, 29 Jun 2009 20:08:10 +0100, Ralf Baechle <ralf@xxxxxxxxxxxxxx> 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 case, no? --- Atsushi Nemoto
