Re: [PATCH] shmem missing cache flush

[Matthew Wilcox <willy@debian.org>]

On Mon, Oct 28, 2002 at 06:26:08AM -0800, David S. Miller wrote:
> If you can't get purely arch/* include/asm-* patches to him,
> that isn't my problem.
> 
> Yes, you might have to retransmit that patch 20/30 times over the
> course of a few days depending upon how busy Linus is, just get over
> it. :-)

I've been more concerned with getting core changes we need to him than
updating arch/parisc and include/asm-parisc.  Maybe I should have been
more pushy.

>    What do you want to do about flush_icache_page?  You want to change it
>    to flush_dcache_page at eviction time, and then we can purge that page
>    from our icache in update_mmu_cache?
>    
> That's the idea.  The other idea is "well these particular call spots
> really are special, so let's document flush_icache_page properly".

What data do you need to make that decision?  AFAICT (I'm not really
a PA CPU guru..) it's exactly the same amount of code, no matter which
way we do it.

While we're on the subject of cache flushing... these make no sense:

fs/binfmt_aout.c:357:           flush_icache_range(text_addr, text_addr+ex.a_text+ex.a_data);
fs/binfmt_aout.c:381:                   flush_icache_range((unsigned long) N_TXTADDR(ex),
fs/binfmt_aout.c:479:           flush_icache_range((unsigned long) start_addr,
fs/binfmt_elf.c:422:    flush_icache_range((unsigned long)addr,

the kernel doesn't execute the code ranges here, userspace does.  Which
means that the only place in the entire kernel which does need to call
flush_icache_range() is kernel/module.c, and that could all be done in
module_arch_init().  So I think we don't need flush_icache_range() at all.

-- 
Revolutions do not require corporate support.