From: anfei.zhou@gmail.com (anfei)
To: linux-arm-kernel@lists.infradead.org
Subject: flush_dcache_page does too much?
Date: Tue, 19 Jan 2010 08:16:36 +0800 [thread overview]
Message-ID: <20100119001636.GA4401@desktop> (raw)
In-Reply-To: <20100118150152.GF2695@n2100.arm.linux.org.uk>
On Mon, Jan 18, 2010 at 03:01:52PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 18, 2010 at 10:57:31PM +0800, anfei wrote:
> > On Mon, Jan 18, 2010 at 02:44:18PM +0000, Russell King - ARM Linux wrote:
> > > On Mon, Jan 18, 2010 at 10:15:30PM +0800, anfei wrote:
> > > > On Mon, Jan 18, 2010 at 02:00:05PM +0000, Russell King - ARM Linux wrote:
> > > > > On Mon, Jan 18, 2010 at 09:54:31PM +0800, anfei wrote:
> > > > > > 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:
> > > > >
> > > > > Your program doesn't do anything to identify any problem. You don't
> > > > > even say _what_ problem you see with this program.
> > > > >
> > > > Sorry for that.
> > > >
> > > > > If you have a specific case which fails, please show the problem, please
> > > > > describe exactly the behaviour that you see, and what you expect to see.
> > >
> > > Are you using a write allocate cache?
> >
> > I guess not, because this line is neccessary to reproduce the issue:
> > tmp = *(addr+0);
> > If it's write allocate, this line may not be neccessary, since it's just
> > a read (and cache the data).
>
> It makes no sense then - without write allocate, writes will go straight
> through to the underlying page, bypassing the cache.
>
Because of the read, the write is cache hitted too even on read allocate:
*(addr+0) = 0x44444444; <- bypass the cache
tmp = *(addr+0); <- read allocate
*(addr+1) = 0x77777777; <- same cacheline, cache hitted
So the two write values are cached, then the sequence in sys_write
cannot guarantee the coherence:
kmap_atomic(page);
copy to page;
kunmap_atomic(page);
flush_dcache_page(page);
It should call flush_dcache_page()@the beginning too in order to
flush the shared mapping. Actually, I think it's better to split this
function into two, such as:
flush_dcache_user_page(page);
copy to page;
kunmap_atomic(page);
flush_dcache_kern_page(page);
And this patch seems to fix it, any other fs doesn't call it need to add
that too.
diff --git a/mm/filemap.c b/mm/filemap.c
index 96ac6b0..07056fb 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2196,6 +2196,9 @@ again:
if (unlikely(status))
break;
+ if (mapping_writably_mapped(mapping))
+ flush_dcache_page(page);
+
pagefault_disable();
copied = iov_iter_copy_from_user_atomic(page, i, offset, bytes);
pagefault_enable();
next prev parent reply other threads:[~2010-01-19 0:16 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
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 [this message]
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=20100119001636.GA4401@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 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.