From: Andrew Morton <[email protected]>
Date: Wed, 18 Oct 2006 23:33:02 -0700
> On Tue, 17 Oct 2006 13:15:37 +0400
> Dmitriy Monakhov <[email protected]> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
