public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: linux-kernel@vger.kernel.org
Cc: jsun@mvista.com, Ralf Baechle <ralf@linux-mips.org>
Subject: Properly implement flush_dcache_page in 2.4?  (Or is it possible?)
Date: Fri, 30 May 2003 10:32:54 -0700	[thread overview]
Message-ID: <20030530103254.B1669@mvista.com> (raw)


My understanding is that if a page is mapped in both user space
and kernel space flush_dcache_page() is used to ensure those mappings
are consistent to each other.

In other words, if the page is modified in user space, kernel needs
to call flush_dcache_page() in order to see the change properly. 
Vice versa.

One immediate problem we have is that given the struct page
pointer argument to this function we have no way of knowing the user 
space virture address of that page (without searching through the whole
page table).  And worse, we might have multiple mappings of the same
page to different user processes at the different virtual addresses.

If a MIPS cpu has a virtually-indexed dcache and has cache aliasing 
problem, we need to know those user space vritual addresses
to flush this page properly.  I suspect some other CPU architectures 
should have this problem too.  True?

So my question is: how other CPU arches with the same problem
implement flush_dcache_page()?  Flushing the whole cache? Or
have a broken implementation and pretend it is OK?  :)

BTW, I assume this is not a big problem in 2.5 as we have reverse page
mapping.

Cheers.

Jun


             reply	other threads:[~2003-05-30 17:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-30 17:32 Jun Sun [this message]
2003-05-30 18:09 ` Properly implement flush_dcache_page in 2.4? (Or is it possible?) Russell King
2003-05-30 23:00   ` Jun Sun
2003-05-30 23:14     ` Russell King
2003-05-31  0:18       ` Jun Sun
2003-05-31  7:24       ` Hugh Dickins
2003-05-31  7:52         ` Russell King
2003-05-31  8:33           ` Hugh Dickins
2003-05-31  9:19             ` Russell King
2003-05-31 10:09               ` Hugh Dickins

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=20030530103254.B1669@mvista.com \
    --to=jsun@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ralf@linux-mips.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox