linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: Query about: ARM11 MPCore: preemption/task migration cache coherency
Date: Fri, 1 Jun 2012 11:29:13 +0800	[thread overview]
Message-ID: <20120601032912.GB16273@mbp> (raw)
In-Reply-To: <4FC81C14.7030702@gmail.com>

On Fri, Jun 01, 2012 at 02:34:12AM +0100, snakky.zhang at gmail.com wrote:
> >> Yes, seems newer CPUs has no such limitation thus this function is global
> >> effective naturally. :-)
> >>
> >> And , I find Mips's c-r4k also has this issue but it use IPI to make it.
> >> Details in arch/mips/mm/c-r4k.c.
> > Rather than IPI we would better use the read-for-ownership trick like
> > in this patch to make flush_dcache_page global (no need for
> > write-for-ownership):
> >
> > http://dchs.spinics.net/lists/arm-kernel/msg125075.html
> >
> > (it may no longer apply, I haven't checked it for some time).
> >
> > That's the first thing. Secondly you still need preemption disable so
> > that it is not preempted between RFO and the actual cache cleaning.
> >
> And, another confusion for PREEMPT: Even if we disable preempt, with locally
> effective flush_dcache_xxx, there is still possibility to reproduce such
> issue(Similar with the previous case):
> 
> 1) Task running on Core-0 loading text section into memory.
>      It was schedule out and then migrate into Core-1;
> 2) On Core-1, this task continue loading it and then
>      "flush_dcache_page" to make sure the loaded text section write
>      into main memory.
> 3) Task tend to the loaded text section and running it.
> 
> Similar as the previous case, the difference lies in step1 that the
> task was interrupted by timer interrupt. Thus it still can be switch
> out and then been migrate to another core. Thus in step2 and 3, this
> issue may still been reproduced.  So, disable preempt can only lower
> the possibility of this issue but can't avoid it.

It would work as long as the data copying into the text area (done by
the driver and VFS layer) and the flush_dcache_page() sequence are not
preemptible. A timer interrupt between data copying and
flush_dcache_page() would interrupt a kernel routine which is not
preemptible.

-- 
Catalin

  reply	other threads:[~2012-06-01  3:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-09  9:11 Query about: ARM11 MPCore: preemption/task migration cache coherency bill4carson
2012-05-11  8:51 ` Will Deacon
2012-05-11  9:53   ` bill4carson
2012-05-29  5:28   ` bill4carson
2012-05-30  6:38     ` Will Deacon
2012-05-30 10:01       ` bill4carson
2012-05-31  3:00         ` Catalin Marinas
2012-05-31  3:11           ` bill4carson
2012-05-31  3:12             ` Catalin Marinas
2012-05-31  3:19             ` Catalin Marinas
2012-05-31  3:38               ` bill4carson
2012-05-31  3:58                 ` Catalin Marinas
2012-05-31  5:06                   ` bill4carson
2012-05-31  5:19                     ` Catalin Marinas
2012-05-31  5:51                       ` bill4carson
2012-05-31  6:56                         ` Catalin Marinas
2012-05-31  7:21                           ` bill4carson
2012-05-31  7:46                             ` snakky.zhang at gmail.com
2012-05-31 16:04                               ` Catalin Marinas
2012-06-01  1:11                                 ` snakky.zhang at gmail.com
2012-06-01  3:25                                   ` Catalin Marinas
2012-06-01  5:21                                     ` snakky.zhang at gmail.com
2012-06-01  1:34                                 ` snakky.zhang at gmail.com
2012-06-01  3:29                                   ` Catalin Marinas [this message]
2012-06-03 11:34                                     ` Russell King - ARM Linux
2012-06-04  9:20                                       ` snakky.zhang at gmail.com
2012-06-05  4:06 ` George G. Davis
2012-06-05  4:50   ` bill4carson
2012-06-06  6:18     ` Andrew Yan-Pai Chen

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=20120601032912.GB16273@mbp \
    --to=catalin.marinas@arm.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).