From: David Miller <davem@davemloft.net>
From: Andrew Morton <akpm@osdl.org>
To: akpm@osdl.org
Cc: dmonakhov@openvz.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm:D-cache aliasing issue in cow_user_page
Date: Thu, 19 Oct 2006 00:00:27 -0700 (PDT) [thread overview]
Date: Wed, 18 Oct 2006 23:33:02 -0700 [thread overview]
Message-ID: <20061019.000027.41635681.davem@davemloft.net> (raw)
In-Reply-To: <20061018233302.a067d1e7.akpm@osdl.org>
> On Tue, 17 Oct 2006 13:15:37 +0400
> Dmitriy Monakhov <dmonakhov@openvz.org> wrote:
>
> > from mm/memory.c:
> > 1434 static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va)
> > 1435 {
> > 1436 /*
> > 1437 * If the source page was a PFN mapping, we don't have
> > 1438 * a "struct page" for it. We do a best-effort copy by
> > 1439 * just copying from the original user address. If that
> > 1440 * fails, we just zero-fill it. Live with it.
> > 1441 */
> > 1442 if (unlikely(!src)) {
> > 1443 void *kaddr = kmap_atomic(dst, KM_USER0);
> > 1444 void __user *uaddr = (void __user *)(va & PAGE_MASK);
> > 1445
> > 1446 /*
> > 1447 * This really shouldn't fail, because the page is there
> > 1448 * in the page tables. But it might just be unreadable,
> > 1449 * in which case we just give up and fill the result with
> > 1450 * zeroes.
> > 1451 */
> > 1452 if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
> > 1453 memset(kaddr, 0, PAGE_SIZE);
> > 1454 kunmap_atomic(kaddr, KM_USER0);
> > #### D-cache have to be flushed here.
> > #### It seems it is just forgotten.
> >
> > 1455 return;
> > 1456
> > 1457 }
> > 1458 copy_user_highpage(dst, src, va);
> > #### Ok here. flush_dcache_page() called from this func if arch need it
> > 1459 }
> >
>
> This page has just been allocated and is private to the caller - there can
> be no userspace mappings of it.
Unfortunately, the kernel has just touched the page and thus there are
active cache lines for the kernel side mapping. When we map this into
user space, userspace might see stale cachelines instead of the
memset() stores.
Architectures typically take care of this in copy_user_page() and
clear_user_page(). The absolutely depend upon those two routines
being used for anonymous pages, and handle the D-cache issues there.
But this code is going outside of that scope, and therefore needs
an explicit D-cache flush.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-10-19 7:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-17 9:15 Dmitriy Monakhov
2006-10-19 6:33 ` Andrew Morton
2006-10-19 7:00 ` David Miller, Andrew Morton [this message]
2006-10-19 7:17 ` Andrew Morton
2006-10-19 7:22 ` David Miller, Andrew Morton
2006-10-19 7:41 ` Andrew Morton
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=20061019.000027.41635681.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=akpm@osdl.org \
--cc=dmonakhov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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