Re: [PATCH] Flushing cache at exit_mmap

From: NIIBE Yutaka (gniibe@chroot.org)
Date: Thu Jul 27 2000 - 00:14:43 EST


Hi, thanks for your attention.

David S. Miller wrote:
> Can you show me a call path to exit_mmap which does not satisfy one of
> the following two cases?

The call sequence in question is:

        kernel/exit.c:do_exit
            kernel/exit.c:__exit_mm
                kernel/fork.c:mmput
                    mm/mmap.c:exit_mmap

> 1) Some function higher in the call path to exit_mmap performs
> a flush_cache_mm/flush_tlb_mm sequence.

There's no flush_cache_mm in the sequence above, neither
flush_cache_range. Actually, I only found two flush_cache_mm at:

   FORK:
        kernel/fork.c:do_fork
            kernel/fork.c:copy_mm
                kernel/fork.c:dup_mmap

   EXEC:
        fs/binfmt_elf.c:load_elf_binary
            fs/exec.c:flush_old_exec
                fs/exec.c:exec_mmap

I think that we also need cache handling for EXIT. How do you think?
I wonder why other architecture doesn't hit this problem.

> because it means that you honestly have a bug somewhere else,
> perhaps in your flush_cache_mm implementation.

That'd be the case, we have to look it again. But in our current
implementation, flush_cache_mm just call flush_cache_all (because of
my lazyness)...

Besides,

Ralf Baechle wrote:
> The cache flush looks fine to me but the TLB flush is not necessary. The
> kernel calls destroy_context(mm) from mmput() rsp. tlb_flush_mm(mm) from
> exec_mmap which already deal with the TLB issues.

Agreed.

-- 

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:23 EST