All of lore.kernel.org
 help / color / mirror / Atom feed
From: kanoj@google.engr.sgi.com (Kanoj Sarcar)
To: ralf@oss.sgi.com (Ralf Baechle)
Cc: manfreds@colorfullife.com, sct@redhat.com, viro@math.psu.edu,
	andrea@suse.de, linux-kernel@vger.rutgers.edu,
	mingo@chiara.csoma.elte.hu, linux-mm@kvack.org,
	linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
	linux-mips@vger.rutgers.edu
Subject: Re: locking question: do_mmap(), do_munmap()
Date: Fri, 15 Oct 1999 10:50:11 -0700 (PDT)	[thread overview]
Message-ID: <199910151750.KAA99441@google.engr.sgi.com> (raw)
In-Reply-To: <19991015115816.B948@uni-koblenz.de> from "Ralf Baechle" at Oct 15, 99 11:58:16 am

> 
> On Wed, Oct 13, 1999 at 09:32:54AM +0200, Manfred Spraul wrote:
> 
> > Kanoj Sarcar wrote:
> > > Here's a primitive patch showing the direction I am thinking of. I do not
> > > have any problem with a spinning lock, but I coded this against 2.2.10,
> > > where insert_vm_struct could go to sleep, hence I had to use sleeping
> > > locks to protect the vma chain.
> > 
> > I found a few places where I don't know how to change them.
> > 
> > 1) arch/mips/mm/r4xx0.c:
> > their flush_cache_range() function internally calls find_vma().
> > flush_cache_range() is called by proc/mem.c, and it seems that this
> > function cannot get the mmap semaphore.
> > Currently, every caller of flush_cache_range() either owns the kernel
> > lock or the mmap_sem.
> > OTHO, this function contains a race anyway [src_vma can go away if
> > handle_mm_fault() sleeps, src_vma is used at the end of the function.]
> 
> The sole reason for fiddling with the VMA is that we try to optimize
> icache flushing for non-VM_EXEC vmas.  This optimization is broken
> as the MIPS hardware doesn't make a difference between read and execute
> in page permissions, so the icache might be dirty even though the vma
> has no exec permission.  So I'll have to re-implement this whole things
> anyway.  The other problem is an efficience problem.  A call like
> flush_cache_range(some_mm_ptr, 0, TASK_SIZE) would take a minor eternity
> and for MIPS64 a full eternity ...
> 
>   Ralf

Ralf,

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? 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
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.

Kanoj

-
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/

WARNING: multiple messages have this Message-ID (diff)
From: kanoj@google.engr.sgi.com (Kanoj Sarcar)
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: manfreds@colorfullife.com, sct@redhat.com, viro@math.psu.edu,
	andrea@suse.de, linux-kernel@vger.rutgers.edu,
	mingo@chiara.csoma.elte.hu, linux-mm@kvack.org,
	linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
	linux-mips@vger.rutgers.edu
Subject: Re: locking question: do_mmap(), do_munmap()
Date: Fri, 15 Oct 1999 10:50:11 -0700 (PDT)	[thread overview]
Message-ID: <199910151750.KAA99441@google.engr.sgi.com> (raw)
In-Reply-To: <19991015115816.B948@uni-koblenz.de> from "Ralf Baechle" at Oct 15, 99 11:58:16 am

> 
> On Wed, Oct 13, 1999 at 09:32:54AM +0200, Manfred Spraul wrote:
> 
> > Kanoj Sarcar wrote:
> > > Here's a primitive patch showing the direction I am thinking of. I do not
> > > have any problem with a spinning lock, but I coded this against 2.2.10,
> > > where insert_vm_struct could go to sleep, hence I had to use sleeping
> > > locks to protect the vma chain.
> > 
> > I found a few places where I don't know how to change them.
> > 
> > 1) arch/mips/mm/r4xx0.c:
> > their flush_cache_range() function internally calls find_vma().
> > flush_cache_range() is called by proc/mem.c, and it seems that this
> > function cannot get the mmap semaphore.
> > Currently, every caller of flush_cache_range() either owns the kernel
> > lock or the mmap_sem.
> > OTHO, this function contains a race anyway [src_vma can go away if
> > handle_mm_fault() sleeps, src_vma is used at the end of the function.]
> 
> The sole reason for fiddling with the VMA is that we try to optimize
> icache flushing for non-VM_EXEC vmas.  This optimization is broken
> as the MIPS hardware doesn't make a difference between read and execute
> in page permissions, so the icache might be dirty even though the vma
> has no exec permission.  So I'll have to re-implement this whole things
> anyway.  The other problem is an efficience problem.  A call like
> flush_cache_range(some_mm_ptr, 0, TASK_SIZE) would take a minor eternity
> and for MIPS64 a full eternity ...
> 
>   Ralf

Ralf,

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? 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
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.

Kanoj
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

  reply	other threads:[~1999-10-15 17:53 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.10.9910101713010.364-100000@alpha.random>
1999-10-10 15:52 ` locking question: do_mmap(), do_munmap() Manfred Spraul
1999-10-10 16:07   ` Alexander Viro
1999-10-10 16:25     ` Alexander Viro
1999-10-10 16:45       ` Manfred Spraul
1999-10-10 17:25         ` Alexander Viro
1999-10-10 17:12       ` Andrea Arcangeli
1999-10-10 17:48         ` Alexander Viro
1999-10-10 18:42           ` Manfred Spraul
1999-10-10 19:03             ` Alexander Viro
1999-10-10 21:31               ` Manfred Spraul
1999-10-10 21:53               ` Andrea Arcangeli
1999-10-10 22:34                 ` Alexander Viro
1999-10-10 23:28                   ` Andrea Arcangeli
1999-10-11 15:50               ` Stephen C. Tweedie
1999-10-11 16:05                 ` Alexander Viro
1999-10-11 18:02                   ` Manfred Spraul
1999-10-11 19:07                     ` Kanoj Sarcar
1999-10-11 22:23                       ` Stephen C. Tweedie
1999-10-13  1:25                         ` Kanoj Sarcar
1999-10-13  7:32                           ` Manfred Spraul
1999-10-13  7:32                             ` Manfred Spraul
1999-10-15  9:58                             ` Ralf Baechle
1999-10-15  9:58                               ` Ralf Baechle
1999-10-15 17:50                               ` Kanoj Sarcar [this message]
1999-10-15 17:50                                 ` Kanoj Sarcar
1999-10-13 10:45                           ` Stephen C. Tweedie
1999-10-11 20:15                     ` Stephen C. Tweedie
1999-10-11 21:14                       ` Manfred Spraul
1999-10-11 21:37                     ` Alexander Viro
1999-10-11 22:13                       ` Manfred Spraul
1999-10-11 22:22                     ` Stephen C. Tweedie
1999-10-11 23:01                       ` Alexander Viro
1999-10-12 14:06                         ` [more fun] " Alexander Viro
1999-10-13  7:35                           ` Manfred Spraul
1999-10-13 18:34                             ` Kanoj Sarcar
1999-10-13 10:16                         ` Stephen C. Tweedie
1999-10-11 20:13                   ` Stephen C. Tweedie
1999-10-11 21:40                     ` Alexander Viro
1999-10-11 22:20                       ` Stephen C. Tweedie
1999-10-11 22:31                         ` Alexander Viro
1999-10-13 10:25                           ` Stephen C. Tweedie
1999-10-11 15:47             ` Stephen C. Tweedie
1999-10-11 15:43         ` Stephen C. Tweedie
1999-10-10 16:56     ` Andrea Arcangeli
1999-10-11 15:41     ` Stephen C. Tweedie
1999-10-11 15:52       ` Alexander Viro
1999-10-09 12:48 Manfred Spraul
1999-10-09 13:12 ` Alexander Viro
1999-10-09 13:17   ` Manfred Spraul
1999-10-09 13:38     ` Alexander Viro
1999-10-09 16:01   ` Andrea Arcangeli
1999-10-10 13:05     ` Manfred Spraul
1999-10-11 15:09       ` Stephen C. Tweedie
1999-10-11 15:05     ` Stephen C. Tweedie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199910151750.KAA99441@google.engr.sgi.com \
    --to=kanoj@google.engr.sgi.com \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mips@fnet.fr \
    --cc=linux-mips@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=linux@cthulhu.engr.sgi.com \
    --cc=manfreds@colorfullife.com \
    --cc=mingo@chiara.csoma.elte.hu \
    --cc=ralf@oss.sgi.com \
    --cc=sct@redhat.com \
    --cc=viro@math.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.