Patchwork powerpc/mm: honor O_SYNC flag for memory mapping

login
register
mail settings
Submitter Yang Li
Date Nov. 26, 2009, 8:02 a.m.
Message ID <1259222529-27645-1-git-send-email-leoli@freescale.com>
Download mbox | patch
Permalink /patch/39492/
State Rejected
Headers show

Comments

Yang Li - Nov. 26, 2009, 8:02 a.m.
There was no way to set mapped memory as cacheable if the memory
is not managed by Linux kernel.  It's not rare in real system to
allocate some dedicated memory to a certain application which is not
managed by kernel and then mmap'ed the memory to the application.
The memory should be cacheable but we can't map it to be cacheable
due to the intelligent setting of cacheability.

The patch makes the cacheability depend on O_SYNC flag of the file
mapped for non-kernel managed memory.  Also prints a deprecation
warning for mmap users without using O_SYNC.

Signed-off-by: Li Yang <leoli@freescale.com>
---
 arch/powerpc/mm/mem.c |   13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)
Paul Mackerras - Nov. 27, 2009, 2:40 a.m.
Li Yang writes:

> There was no way to set mapped memory as cacheable if the memory
> is not managed by Linux kernel.  It's not rare in real system to
> allocate some dedicated memory to a certain application which is not
> managed by kernel and then mmap'ed the memory to the application.
> The memory should be cacheable but we can't map it to be cacheable
> due to the intelligent setting of cacheability.
> 
> The patch makes the cacheability depend on O_SYNC flag of the file
> mapped for non-kernel managed memory.  Also prints a deprecation
> warning for mmap users without using O_SYNC.

NAK, since it is an incompatible change to the kernel ABI.

What sort of memory is this that you want to map as cacheable?  Is it
normal system RAM that your platform code reserves, or is it some
other kind of memory?

If it's the normal system RAM, you could make phys_mem_access_prot()
smart enough to recognize that (by looking in the lmb array or the
device tree).

If it's another kind of memory, it should be described in the device
tree, and you could have a platform-specific phys_mem_access_prot
function for your platform that looks in the device tree to see if the
memory being mapped is this special sort of memory.

Paul.

Patch

diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 579382c..b9ef77a 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -101,8 +101,17 @@  pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 	if (ppc_md.phys_mem_access_prot)
 		return ppc_md.phys_mem_access_prot(file, pfn, size, vma_prot);
 
-	if (!page_is_ram(pfn))
-		vma_prot = pgprot_noncached(vma_prot);
+	/* kernel managed memory is always cacheable, otherwise is controlled
+	 * by O_SYNC flag of open() */
+	if (!page_is_ram(pfn)) {
+		if (file->f_flags & O_SYNC)
+			vma_prot = pgprot_noncached(vma_prot);
+		else
+			printk(KERN_WARNING
+				"Warning: mmap on file without O_SYNC will be "
+				"mapped as cacheable.  Make sure it is desired."
+				"\n");
+	}
 
 	return vma_prot;
 }