Re: [PATCH] mm:D-cache aliasing issue in cow_user_page

[David Miller <davem@davemloft.net>]

From: Andrew Morton <akpm@osdl.org>
Date: Wed, 18 Oct 2006 23:33:02 -0700

> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/