linux-mips
[Top] [All Lists]

Re: [PATCH] remap_file_pages needs to check for cache coherency

To: David Miller <davem@davemloft.net>
Subject: Re: [PATCH] remap_file_pages needs to check for cache coherency
From: Matthew Wilcox <willy@linux.intel.com>
Date: Fri, 27 Dec 2013 14:20:41 -0500
Cc: linux-mm@kvack.org, sparclinux@vger.kernel.org, linux-parisc@vger.kernel.org, linux-mips@linux-mips.org
In-reply-to: <20131227.134814.345379118522548543.davem@davemloft.net>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20131227180018.GC4945@linux.intel.com> <20131227.134814.345379118522548543.davem@davemloft.net>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Dec 27, 2013 at 01:48:14PM -0500, David Miller wrote:
> From: Matthew Wilcox <willy@linux.intel.com>
> Date: Fri, 27 Dec 2013 13:00:18 -0500
> 
> > It seems to me that while (for example) on SPARC, it's not possible to
> > create a non-coherent mapping with mmap(), after we've done an mmap,
> > we can then use remap_file_pages() to create a mapping that no longer
> > aliases in the D-cache.
> > 
> > I have only compile-tested this patch.  I don't have any SPARC hardware,
> > and my PA-RISC hardware hasn't been turned on in six years ... I noticed
> > this while wandering around looking at some other stuff.
> 
> I suppose this is needed, but only in the case where the mapping is
> shared and writable, right?  I don't see you testing those conditions,
> but with them I'd be OK with this change.

VM_SHARED is checked a few lines above; too far to be visible in the
original context diff:

        if (!vma || !(vma->vm_flags & VM_SHARED))
                goto out;
 
        if (!vma->vm_ops || !vma->vm_ops->remap_pages)
                goto out;
 
        if (start < vma->vm_start || start + size > vma->vm_end)
                goto out;
 
+#ifdef __ARCH_FORCE_SHMLBA
+       /* Is the mapping cache-coherent? */
+       if ((pgoff ^ linear_page_index(vma, start)) &
+           ((SHMLBA-1) >> PAGE_SHIFT))
+               goto out;
+#endif

I don't understand why we need to check for writable here.  We don't
seem to check VM_WRITE in arch_get_unmapped_area(), so I don't see why
we should be checking it here.  Put it another way; if I mmap() a file
with PROT_READ only, should I be able to see stale data after another
thread has written to it?

<Prev in Thread] Current Thread [Next in Thread>