[Top] [All Lists]

Re: locking question: do_mmap(), do_munmap()

To: Kanoj Sarcar <>
Subject: Re: locking question: do_mmap(), do_munmap()
From: Ralf Baechle <>
Date: Mon, 18 Oct 1999 10:37:33 +0200
In-reply-to: <>
References: <> <>
On Fri, Oct 15, 1999 at 10:50:11AM -0700, Kanoj Sarcar wrote:

> Looking in 2.3.21, all the find_vma's in arch/mips/mm/r4xx0.c are used to 
> set a flag called "text" which is not used at all. Also, if the find_vma
> returns null, the code basically does nothing. So the optimized icache
> flushing is probably not implemented yet?

Not my day when I wrote my last posting ...  I was actually looking at
r4k_flush_cache_page* which gets a vma argument passed in, so they doesn't
do a find_vma.  That use of the text flag there is broken.  Scenario:

 1) a process tries to execute code in a vma with VM_READ set but VM_EXEC
    clear, thereby poluting the i-cache.
 2) context switch to another process on this same CPU.
 3) this second process faults on a non-present code page.  The virtual address
    happens to be one of those that are in the i-cache from 1).
 4) mm steals a page of that vma which is cached in the i-cache.
 5) flush_cache_page will be called but will skip i-cache flushing because
    the page isn't VM_EXEC.
 6) do_no_page knows that the page cannot yet have entered a cache, therefore
    skips cache flushing completly.
 7) New process executes code from old process.

Or is there a reason why this cannot happen?

> Then, the only reason to do the flush_vma currently is to check whether
> the lower level flush routine should be called. Without holding some
> locks, this is always tricky to do on a third party mm.

> Btw, this probably belongs to linux-mips, but what do you mean by saying

Yep, cc-list truncated heavily.

> the icache might be dirty? Its been a while since I worked on the
> older mips chips, but as far as I remember, the icache can not hold 
> dirty lines.

Braino, I meant the valid state of the i-Cache.  The problem is that an
attempt to execute a page which's vma doesn't have VM_EXEC but VM_READ set
may still pollute the the i-cache.  So we must flush the i-cache in any
case or a later re-use of the affected physical pages at the same virtual
address might do funny things.

(On the R3000 which allows swapping of i-cache and d-cache for diagnostic
purposes it actually is possible to have dirty lines in the d-cache when
it's used as the i-cache.  But that's not a consideration for Linux.)


<Prev in Thread] Current Thread [Next in Thread>