From: Jun Sun <jsun@mvista.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org,
rmk@arm.linux.org.uk, jsun@mvista.com
Subject: Re: [BUG] 2.6.1/MIPS - missing cache flushing when user program returns pages to kernel
Date: Wed, 14 Jan 2004 17:40:12 -0800 [thread overview]
Message-ID: <20040114174012.H13471@mvista.com> (raw)
In-Reply-To: <20040114172946.03e54706.akpm@osdl.org>; from akpm@osdl.org on Wed, Jan 14, 2004 at 05:29:46PM -0800
On Wed, Jan 14, 2004 at 05:29:46PM -0800, Andrew Morton wrote:
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > I think that's wrong, really. We've discussed this before and decided that
> > these flushing operations should be open-coded in the main .c file rather
> > than embedded in arch functions which happen to undocumentedly do other
> > stuff.
>
> err, OK, I give up. Lots of architectures do the cache flush in
> tlb_start_vma(). I guess mips may as well do the same.
>
Looking at my tree (which is from linux-mips.org), it appears
arm, sparc, sparc64, and sh have tlb_start_vma() defined to call
cache flushing.
What exactly does tlb_start_vma()/tlb_end_vma() mean? There is
only one invocation instance, which is significant enough to infer
the meaning. :)
BTW, either my original hack or putting a cache flush in tlb_start_vma()
solves my problem. They are really doing the same thing, just at
different places.
Jun
next prev parent reply other threads:[~2004-01-15 1:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-15 0:39 [BUG] 2.6.1/MIPS - missing cache flushing when user program returns pages to kernel Jun Sun
2004-01-15 1:12 ` Andrew Morton
2004-01-15 1:12 ` Andrew Morton
2004-01-15 1:29 ` Andrew Morton
2004-01-15 1:40 ` Jun Sun [this message]
2004-01-15 6:23 ` David S. Miller
2004-01-15 6:23 ` David S. Miller
2004-01-15 18:03 ` Jun Sun
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=20040114174012.H13471@mvista.com \
--to=jsun@mvista.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=rmk@arm.linux.org.uk \
/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.