From: pullip@gmail.com (Cho, Kyong Ho)
To: linux-arm-kernel@lists.infradead.org
Subject: Why flush_cache_vmap flushes all levels of the cache?
Date: Fri, 9 Apr 2010 09:45:48 +0900 [thread overview]
Message-ID: <t2gaf12251d1004081745m34787345i39c4b17ef5c1e87b@mail.gmail.com> (raw)
In-Reply-To: <s2naf12251d1004081743k79760c5p10dfd2d07fcbec94@mail.gmail.com>
Hi.
Even though flush_cache_vmap(arch/arm/include/asm/cacheflush.h), that
is invoked whenever a new VM-PM mapping on the HIMEM is created, does
not flush the entire cache for non-aliasing VIPT caches from 2.6.30, I
am curious why it must flush the entire cache for other caches such as
VIVT or VIPT prior to ARMv7.
static inline void flush_cache_vmap(unsigned long start, unsigned long end)
{
?? ? ? ?if (!cache_is_vipt_nonaliasing())
?? ? ? ? ? ? ? ?flush_cache_all();
?? ? ? ?else
?? ? ? ? ? ? ? ?/*
?? ? ? ? ? ? ? ? * set_pte_at() called from vmap_pte_range() does not
?? ? ? ? ? ? ? ? * have a DSB after cleaning the cache line.
?? ? ? ? ? ? ? ? */
?? ? ? ? ? ? ?dsb();
}
I guess the following situation:
(1) A cache line contains stale, dirty data that is allocated by an
old page mapping and is not flushed when the page mapping is removed
(but as far as I know, flush_cache_vunmap is always invoked whenever a
page mapping is removed)
(2) New page mapping on the HIMEM is created.
(3) Data in the page frame mapped by (2) is modified through the new
page mapping
(4) After a while, the cache line that I mentioned in (1) still
contains stale data by the old page mapping and becomes a victim.
(5) Data in the cache line is flushed into the main memory even though
no page mapping exists
As a result of the above situation, the main memory is modified by an
invalid data and not coherent with the cache.
Is my assumption correct?
parent reply other threads:[~2010-04-09 0:45 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <s2naf12251d1004081743k79760c5p10dfd2d07fcbec94@mail.gmail.com>]
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=t2gaf12251d1004081745m34787345i39c4b17ef5c1e87b@mail.gmail.com \
--to=pullip@gmail.com \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).