linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dirk.behme@googlemail.com (Dirk Behme)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 10/11] ARM: arrange for flush_cache_range() to always	flush the I-cache
Date: Mon, 16 Nov 2009 12:06:08 +0100	[thread overview]
Message-ID: <4B013220.10307@googlemail.com> (raw)
In-Reply-To: <1258368415.6705.20.camel@pc1117.cambridge.arm.com>

Catalin Marinas wrote:
> Russell,
> 
> On Thu, 2009-10-29 at 17:51 +0000, Catalin Marinas wrote:
>> On Wed, 2009-10-28 at 17:37 +0000, Russell King - ARM Linux wrote:
>>>  I'm not entirely
>>> sure what's happening with the other half of the fix (the thread seemed
>>> to die before reaching any kind of conclusion) but this is the right
>>> solution for the I-cache side of the problem.
>> I listed a few solutions there but not many replies. Let's try to sort
>> it out in this thread (maybe people got bored and ignored the other
>> thread completely :-)).
> [...]
>> Flush the D-cache during copy_user_highpage()
>>
>> From: Catalin Marinas <catalin.marinas@arm.com>
>>
>> The I and D caches for copy-on-write pages on processors with
>> write-allocate caches become incoherent causing problems on application
>> relying on CoW for text pages (dynamic linker relocating symbols in a
>> text page). This patch flushes the D-cache for such pages.
>>
>> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>> ---
>>  arch/arm/mm/copypage-v6.c |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mm/copypage-v6.c b/arch/arm/mm/copypage-v6.c
>> index 4127a7b..f19ed4e 100644
>> --- a/arch/arm/mm/copypage-v6.c
>> +++ b/arch/arm/mm/copypage-v6.c
>> @@ -41,6 +41,7 @@ static void v6_copy_user_highpage_nonaliasing(struct page *to,
>>  	kfrom = kmap_atomic(from, KM_USER0);
>>  	kto = kmap_atomic(to, KM_USER1);
>>  	copy_page(kto, kfrom);
>> +	__cpuc_flush_dcache_page(kto);
>>  	kunmap_atomic(kto, KM_USER1);
>>  	kunmap_atomic(kfrom, KM_USER0);
>>  }
> 
> Any thoughts one getting this merged (maybe in 2.6.33)? It seems that
> no-one else has any views on this but the COW text pages problem is
> still present.

Yes. ARM11MPCore still suffers from this issue. Please understand my 
silence as "I can't help with the discussion about this" :( And not 
"I'm not interested in it any more".

Many thanks for all the work you spent with this,

Dirk

  parent reply	other threads:[~2009-11-16 11:06 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-27 22:40 [RFC 00/11] Cache handling updates Russell King
2009-10-24 13:11 ` [RFC 01/11] ARM: Reduce __flush_dcache_page() visibility Russell King
2009-10-24 21:36 ` [RFC 02/11] ARM: Fix errata 411920 workarounds Russell King
2009-10-28 15:31   ` Catalin Marinas
2009-10-28 17:32     ` Russell King - ARM Linux
2009-10-29 18:32       ` Catalin Marinas
2009-10-29 19:11         ` Russell King - ARM Linux
2009-10-30 17:59           ` Catalin Marinas
2009-10-24 21:58 ` [RFC 03/11] ARM: move __flush_icache_all() out of flush_pfn_alias() Russell King
2009-10-24 22:05 ` [RFC 04/11] ARM: Remove __flush_icache_all() from __flush_dcache_page() Russell King
2009-10-25 10:23 ` [RFC 05/11] ARM: Avoid flush_dcache_page() for zero page Russell King
2009-10-25 10:40 ` [RFC 06/11] ARM: Avoid duplicated implementation for VIVT cache flushing Russell King
2009-10-25 10:59 ` [RFC 07/11] ARM: Allocate ZERO_PAGE from highmem Russell King
2009-12-04 14:57   ` Russell King - ARM Linux
2009-10-25 11:25 ` [RFC 08/11] ARM: Avoid evaluating page_address() multiple times Russell King
2009-10-25 13:35 ` [RFC 09/11] ARM: Add I-cache invalidation for VIVT ASID tagged caches Russell King
2009-10-28 15:49   ` Catalin Marinas
2009-10-28 17:35     ` Russell King - ARM Linux
2009-10-29 17:23       ` Catalin Marinas
2009-10-25 14:12 ` [RFC 10/11] ARM: arrange for flush_cache_range() to always flush the I-cache Russell King
2009-10-28 15:51   ` Catalin Marinas
2009-10-28 17:37     ` Russell King - ARM Linux
2009-10-29 17:51       ` Catalin Marinas
2009-11-16 10:46         ` Catalin Marinas
2009-11-16 10:58           ` Russell King - ARM Linux
2009-11-22 20:28             ` Nicolas Pitre
2009-11-23 20:28               ` Russell King - ARM Linux
2009-11-24 13:05                 ` [RFC 10/11] ARM: arrange for flush_cache_range() to alwaysflush " Catalin Marinas
2009-11-24 14:46                   ` Russell King - ARM Linux
2009-11-24 16:52                     ` [RFC 10/11] ARM: arrange for flush_cache_range() toalwaysflush " Catalin Marinas
2009-11-24 16:56                       ` Russell King - ARM Linux
2009-11-16 11:06           ` Dirk Behme [this message]
2009-10-25 14:31 ` [RFC 11/11] ARM: avoid flushing I-cache in flush_cache_mm() Russell King
2009-11-13 15:01   ` Gilles Chanteperdrix
2009-11-13 15:12     ` Russell King
2009-11-13 15:15       ` Gilles Chanteperdrix
2009-10-28 15:53 ` [RFC 00/11] Cache handling updates Catalin Marinas
2009-10-28 16:17 ` Laurent Pinchart
2009-10-28 16:28   ` Catalin Marinas
2009-11-05 19:19     ` Pavel Machek
2009-10-28 17:41   ` Russell King - ARM Linux
2009-10-28 19:25     ` Laurent Pinchart

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=4B013220.10307@googlemail.com \
    --to=dirk.behme@googlemail.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).