linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: anfei.zhou@gmail.com (anfei)
To: linux-arm-kernel@lists.infradead.org
Subject: flush_dcache_page does too much?
Date: Mon, 18 Jan 2010 21:54:31 +0800	[thread overview]
Message-ID: <20100118135431.GA12496@desktop> (raw)
In-Reply-To: <20100118133304.GA29645@n2100.arm.linux.org.uk>

On Mon, Jan 18, 2010 at 01:33:04PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 18, 2010 at 09:13:46PM +0800, anfei wrote:
> > I'm studying the cache alias problem especially of VIPT, I found
> > function flush_dcache_page() does much more operations on ARM than MIPS.
> > Can we not flush the userspace mappings and icache, just like MIPS?
> > Are the cache more consistent with these operations?
> > 
> > As far as I know, flush_dcache_page is usually used as this:
> >         kmap_atomic(page, ...);
> >         write the page;
> >         flush_dcache_page(page);
> >         kunmap_atomic(...);
> > called in the path of write()/..., but since mmap() + write() is not
> > ensured to work (even on ARM currently), it's the userspace to consider
> > msync()/munmap(), it looks okay without flush the userspace mappings
> > here.  Other cases seem the same if the userspace takes charge of the 
> > cache problem.
> 
> On VIPT on ARM, flush_dcache_page() flushes:
> 
> 1. the direct kernel mapping and aliases of that (which read()/write()
>    will touch.)
> 
> 2. the user aliases, which may not be coherent with the direct kernel
>    mapping.
> 
> It is unsafe to avoid dealing with any of those - and doing so will cause
> shared mappings to be incoherent with filesystem IO.

Do you mean this implementation can ensure the coherence between write
and shared mmapings?  But it's easy to reproduce the alias problem by
this simple testcase (w/o error handler) on omap2430 with VIPT cache:

---
#include <stdio.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main(void)
{
        int fd;
        int *addr;
        int tmp;
        int val = 0x11111111;

        fd = open("abc", O_RDWR);
        addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
        *(addr+0) = 0x44444444;
        tmp = *(addr+0);
        *(addr+1) = 0x77777777;
        write(fd, &val, sizeof(int));
        close(fd);

        return 0;
}

  reply	other threads:[~2010-01-18 13:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-18 13:13 flush_dcache_page does too much? anfei
2010-01-18 13:33 ` Russell King - ARM Linux
2010-01-18 13:54   ` anfei [this message]
2010-01-18 14:00     ` Russell King - ARM Linux
2010-01-18 14:15       ` anfei
2010-01-18 14:44         ` Russell King - ARM Linux
2010-01-18 14:53           ` anfei
2010-01-18 14:57           ` anfei
2010-01-18 15:01             ` Russell King - ARM Linux
2010-01-19  0:16               ` anfei
2010-01-19 13:05                 ` anfei
2010-01-19 17:44                   ` Russell King - ARM Linux
2010-01-19 18:33                     ` Jamie Lokier

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=20100118135431.GA12496@desktop \
    --to=anfei.zhou@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).