From: rabin@rab.in (Rabin Vincent)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 2/4] ARM: Assume new page cache pages have dirty D-cache
Date: Wed, 23 Jun 2010 01:06:38 +0530 [thread overview]
Message-ID: <20100622193638.GA9780@debian> (raw)
In-Reply-To: <20100621144632.26309.63314.stgit@e102109-lin.cambridge.arm.com>
On Mon, Jun 21, 2010 at 03:46:32PM +0100, Catalin Marinas wrote:
> There are places in Linux where writes to newly allocated page cache
> pages happen without a subsequent call to flush_dcache_page() (several
> PIO drivers including USB HCD). This patch changes the meaning of
> PG_arch_1 to be PG_dcache_clean and always flush the D-cache for a newly
> mapped page in update_mmu_cache().
Correct me if I'm misreading the code, but don't this patch and the next
one make the assumption that CONFIG_SMP == VIPT non-aliasing (or PIPT)
caches? This patch does not add flushing on SMP systems, and the next
one handles the I$-D$ coherency issues there (ignoring the set_pte race
fix for a moment). Won't the flushing added in this patch be
unnecessary on non-SMP PIPT systems, since they too only need the
exec-related flushing?
Rabin
next prev parent reply other threads:[~2010-06-22 19:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-21 14:46 [PATCH v4 0/4] Patches for -next Catalin Marinas
2010-06-21 14:46 ` [PATCH v4 1/4] ARM: Remove the domain switching on ARMv6k/v7 CPUs Catalin Marinas
2010-06-22 12:47 ` Anton Vorontsov
2010-06-22 13:01 ` Catalin Marinas
2010-06-21 14:46 ` [PATCH v4 2/4] ARM: Assume new page cache pages have dirty D-cache Catalin Marinas
2010-06-22 19:36 ` Rabin Vincent [this message]
2010-06-22 22:39 ` Catalin Marinas
2010-06-21 14:46 ` [PATCH v4 3/4] ARM: Synchronise the I and D caches via set_pte_at() on SMP systems Catalin Marinas
2010-06-21 14:46 ` [PATCH v4 4/4] ARM: Use lazy cache flushing on ARMv7 " Catalin Marinas
2010-06-22 10:29 ` [PATCH v4 0/4] Patches for -next Rabin Vincent
2010-06-22 11:34 ` Catalin Marinas
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=20100622193638.GA9780@debian \
--to=rabin@rab.in \
--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 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.