linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] ARM64: Kernel managed pages are only flushed
@ 2014-03-05 11:20 Bharat Bhushan
  2014-03-06  6:53 ` Catalin Marinas
  0 siblings, 1 reply; 11+ messages in thread
From: Bharat Bhushan @ 2014-03-05 11:20 UTC (permalink / raw)
  To: linux-arm-kernel

Kernel can only access pages which maps to managed memory.
So flush only valid kernel pages.

I observed kernel crash direct assigning a device using VFIO
and found that it was caused because of accessing invalid page

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/arm64/mm/flush.c |   13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
index e4193e3..2b4e8b0 100644
--- a/arch/arm64/mm/flush.c
+++ b/arch/arm64/mm/flush.c
@@ -72,7 +72,18 @@ void copy_to_user_page(struct vm_area_struct *vma, struct page *page,
 
 void __sync_icache_dcache(pte_t pte, unsigned long addr)
 {
-	struct page *page = pte_page(pte);
+	struct page *page;
+
+#ifdef CONFIG_HAVE_ARCH_PFN_VALID
+	/*
+	 * We can only access pages that the kernel maps
+	 * as memory. Bail out for unmapped ones.
+	 */
+	if (!pfn_valid(pfn))
+		return;
+
+#endif
+	page = pte_page(pte);
 
 	/* no flushing needed for anonymous pages */
 	if (!page_mapping(page))
-- 
1.7.0.4

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH] ARM64: Kernel managed pages are only flushed
  2014-03-05 11:20 [PATCH] ARM64: Kernel managed pages are only flushed Bharat Bhushan
@ 2014-03-06  6:53 ` Catalin Marinas
  2014-03-06  9:33   ` Bharat.Bhushan at freescale.com
  2014-03-12 14:41   ` Bharat.Bhushan at freescale.com
  0 siblings, 2 replies; 11+ messages in thread
From: Catalin Marinas @ 2014-03-06  6:53 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Mar 05, 2014 at 04:50:46PM +0530, Bharat Bhushan wrote:
> Kernel can only access pages which maps to managed memory.
> So flush only valid kernel pages.
> 
> I observed kernel crash direct assigning a device using VFIO
> and found that it was caused because of accessing invalid page

I don't get this. Could you please share some kernel crash message to
see the backtrace? The __sync_icache_dcache() function is called from
set_pte_at() if the pte is valid, user and exec. If these are correct,
why does it crash? Actually, does the cache maintenance crash or
page_mapping()?

-- 
Catalin

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH] ARM64: Kernel managed pages are only flushed
  2014-03-06  6:53 ` Catalin Marinas
@ 2014-03-06  9:33   ` Bharat.Bhushan at freescale.com
  2014-03-12 14:41   ` Bharat.Bhushan at freescale.com
  1 sibling, 0 replies; 11+ messages in thread
From: Bharat.Bhushan at freescale.com @ 2014-03-06  9:33 UTC (permalink / raw)
  To: linux-arm-kernel



> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas at gmail.com] On Behalf Of Catalin
> Marinas
> Sent: Thursday, March 06, 2014 12:24 PM
> To: Bhushan Bharat-R65777
> Cc: will.deacon at arm.com; linux-arm-kernel at lists.infradead.org; Bhushan Bharat-
> R65777
> Subject: Re: [PATCH] ARM64: Kernel managed pages are only flushed
> 
> On Wed, Mar 05, 2014 at 04:50:46PM +0530, Bharat Bhushan wrote:
> > Kernel can only access pages which maps to managed memory.
> > So flush only valid kernel pages.
> >
> > I observed kernel crash direct assigning a device using VFIO and found
> > that it was caused because of accessing invalid page
> 
> I don't get this. Could you please share some kernel crash message to see the
> backtrace? The __sync_icache_dcache() function is called from
> set_pte_at() if the pte is valid, user and exec. If these are correct, why does
> it crash? Actually, does the cache maintenance crash or page_mapping()?

It fails in page_mapping() because it access page of non-kernel visible memory. I am not a memory management expert and according to my understanding there can be valid pte but may not a valid struct page. Valid struct page exists only for kernel managed memory.


Kernel crash dump (address 0x80c6a0, size: 0x1000; This is the physical address of a device which I am direct assigning to userspace application named Layerscape using VFIO):

Unable to handle kernel paging request at virtual address ffffffbc1c2b7308
pgd = ffffffc0595ea000
[ffffffbc1c2b7308] *pgd=0000000000000000
Internal error: Oops: 96000006 [#1]
Modules linked in:
CPU: 0 PID: 656 Comm: layerscape Not tainted 3.12.0+ #66
task: ffffffc059566e80 ti: ffffffc059294000 task.ti: ffffffc059294000
PC is at page_mapping+0x0/0x14
LR is at __sync_icache_dcache+0x2c/0xb8
pc : [<ffffffc0000f9cac>] lr : [<ffffffc000090554>] pstate: 60000145
sp : ffffffc059297bc0
x29: ffffffc059297bc0 x28: 0000007fb5cce000 
x27: 0000000000000041 x26: 0020000000000c43 
x25: 0000007fb5ccf000 x24: ffffffc0595b0670 
x23: 000000000080c6a0 x22: 002000080c6a0c43 
x21: 012000080c6a0c43 x20: 0000007fb5ccf000 
x19: ffffffbc1c2b7300 x18: 0000007fd7b45500 
x17: 0000000000412268 x16: 0000000000000004 
x15: 0000000000000002 x14: 0000000000000000 
x13: 0000000000003958 x12: 0000000000000048 
x11: 0000000000000013 x10: 00000000000000f0 
x9 : 0000000000000002 x8 : 0000007fb5ece000 
x7 : 0000000000000028 x6 : ffffffc00051b590 
x5 : 0000000000000670 x4 : 0020000000000c43 
x3 : ffffffc000000000 x2 : ffffffc0595b0000 
x1 : ffffffbc00000000 x0 : ffffffbc1c2b7300 
Process layerscape (pid: 656, stack limit = 0xffffffc059294058)
Stack: (0xffffffc059297bc0 to 0xffffffc059298000)
7bc0: 59297be0 ffffffc0 00102510 ffffffc0 59766d70 ffffffc0 ffffffc8 00000000
7be0: 59297c70 ffffffc0 002b51fc ffffffc0 595fd2c0 ffffffc0 596e78d8 ffffffc0
7c00: 00001000 00000000 0c6a0000 00000008 5969c4f8 ffffffc0 00000001 00000000
7c20: 595b1a00 ffffffc0 00000000 00000000 0047e558 ffffffc0 0047e548 ffffffc0
7c40: 59cff080 ffffffc0 b5ccefff 0000007f b5ccf000 0000007f 595eaff0 ffffffc0
7c60: f88569d2 ffffffff b5ccefff 0000007f 59297d00 ffffffc0 002b1cc4 ffffffc0
7c80: 595fd448 ffffffc0 b5cce000 0000007f 595fd440 ffffffc0 00000001 00000000
7ca0: 000000ff 00000000 59294000 ffffffc0 59cff080 ffffffc0 00000000 00000000
7cc0: 00000000 00000000 595fd420 ffffffc0 59297ce0 ffffffc0 595b1000 ffffffc0
7ce0: 0c6a1000 00000008 00001000 00000000 0047e5a0 ffffffc0 0047e580 ffffffc0
7d00: 59297d20 ffffffc0 00108968 ffffffc0 00000000 00000000 00000001 00000000
7d20: 59297da0 ffffffc0 00108e34 ffffffc0 00000007 00000000 000000ff 00000000
7d40: 595d36c0 ffffffc0 00000001 00000000 59cff080 ffffffc0 00001000 00000000
7d60: 00000001 00000000 b5cce000 0000007f 00000007 00000000 59294000 ffffffc0
7d80: 00000007 00000000 595fd2c0 ffffffc0 0080c6a0 00000000 595d36c0 ffffffc0
7da0: 59297e10 ffffffc0 000f9c40 ffffffc0 59cff0d8 ffffffc0 595d36c0 ffffffc0
7dc0: 00000000 00000000 0080c6a0 00000000 595d36c0 ffffffc0 00000015 00000000
7de0: 00000112 00000000 000000de 00000000 004ed000 ffffffc0 000f9c20 ffffffc0
7e00: 59297e68 ffffffc0 0080c6a0 00000000 59297e70 ffffffc0 00107508 ffffffc0
7e20: 00000001 00000000 00001000 00000000 59297e80 ffffffc0 0080c6a0 00000000
7e40: 00000001 00000000 00000003 00000000 00001000 00000000 00000000 00000000
7e60: 60000000 00000000 00000000 00000000 59297ec0 ffffffc0 00086d80 ffffffc0
7e80: 00000000 00000000 00000000 00000000 ffffffff ffffffff b5c2355c 0000007f
7ea0: 80000000 00000000 b5c1ffcc 0000007f 80000000 00000000 00000003 00000000
7ec0: d7b45720 0000007f 000839ec ffffffc0 00000000 00000000 00001000 00000000
7ee0: 00000003 00000000 00000001 00000000 00000005 00000000 0c6a0000 00000008
7f00: 00401884 00000000 00000000 00000000 000000de 00000000 b5ca35d0 0000007f
7f20: ffffffff 00000000 00000008 00000000 00000038 00000000 ffffffff ffffffff
7f40: 00000040 00000000 b5cd3028 0000007f b5c23548 0000007f 00412268 00000000
7f60: d7b45500 0000007f 00000000 00000000 00000000 00000000 004008c0 00000000
7f80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fa0: 00000000 00000000 00000000 00000000 00000000 00000000 d7b45720 0000007f
7fc0: 00400e38 00000000 d7b45720 0000007f b5c2355c 0000007f 80000000 00000000
7fe0: 00000000 00000000 000000de 00000000 00000000 00000000 00000000 00000000
Call trace:
[<ffffffc0000f9cac>] page_mapping+0x0/0x14
[<ffffffc000102510>] remap_pfn_range+0x1cc/0x324
[<ffffffc0002b51fc>] vfio_layerscape_mmap+0x22c/0x248
[<ffffffc0002b1cc4>] vfio_device_fops_mmap+0x20/0x30
[<ffffffc000108968>] mmap_region+0x320/0x538
[<ffffffc000108e34>] do_mmap_pgoff+0x2b4/0x320
[<ffffffc0000f9c40>] vm_mmap_pgoff+0x60/0x90
[<ffffffc000107508>] SyS_mmap_pgoff+0x88/0xc4
[<ffffffc000086d80>] sys_mmap+0x18/0x28
Code: a8c17bfd d65f03c0 928002a0 17fffffd (f9400400) 
---[ end trace 650769ec4955b30e ]---

> 
> --
> Catalin
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH] ARM64: Kernel managed pages are only flushed
  2014-03-06  6:53 ` Catalin Marinas
  2014-03-06  9:33   ` Bharat.Bhushan at freescale.com
@ 2014-03-12 14:41   ` Bharat.Bhushan at freescale.com
  2014-03-12 14:56     ` Will Deacon
  1 sibling, 1 reply; 11+ messages in thread
From: Bharat.Bhushan at freescale.com @ 2014-03-12 14:41 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Catalin,

> 
> > -----Original Message-----
> > From: Catalin Marinas [mailto:catalin.marinas at gmail.com] On Behalf Of
> > Catalin Marinas
> > Sent: Thursday, March 06, 2014 12:24 PM
> > To: Bhushan Bharat-R65777
> > Cc: will.deacon at arm.com; linux-arm-kernel at lists.infradead.org; Bhushan
> > Bharat-
> > R65777
> > Subject: Re: [PATCH] ARM64: Kernel managed pages are only flushed
> >
> > On Wed, Mar 05, 2014 at 04:50:46PM +0530, Bharat Bhushan wrote:
> > > Kernel can only access pages which maps to managed memory.
> > > So flush only valid kernel pages.
> > >
> > > I observed kernel crash direct assigning a device using VFIO and
> > > found that it was caused because of accessing invalid page
> >
> > I don't get this. Could you please share some kernel crash message to
> > see the backtrace? The __sync_icache_dcache() function is called from
> > set_pte_at() if the pte is valid, user and exec. If these are correct,
> > why does it crash? Actually, does the cache maintenance crash or
> page_mapping()?
> 
> It fails in page_mapping() because it access page of non-kernel visible memory.
> I am not a memory management expert and according to my understanding there can
> be valid pte but may not a valid struct page. Valid struct page exists only for
> kernel managed memory.
> 
> 
> Kernel crash dump (address 0x80c6a0, size: 0x1000; This is the physical address
> of a device which I am direct assigning to userspace application named
> Layerscape using VFIO):
> 
> Unable to handle kernel paging request at virtual address ffffffbc1c2b7308 pgd =
> ffffffc0595ea000 [ffffffbc1c2b7308] *pgd=0000000000000000 Internal error: Oops:
> 96000006 [#1] Modules linked in:
> CPU: 0 PID: 656 Comm: layerscape Not tainted 3.12.0+ #66
> task: ffffffc059566e80 ti: ffffffc059294000 task.ti: ffffffc059294000 PC is at
> page_mapping+0x0/0x14 LR is at __sync_icache_dcache+0x2c/0xb8 pc :
> [<ffffffc0000f9cac>] lr : [<ffffffc000090554>] pstate: 60000145 sp :
> ffffffc059297bc0
> x29: ffffffc059297bc0 x28: 0000007fb5cce000
> x27: 0000000000000041 x26: 0020000000000c43
> x25: 0000007fb5ccf000 x24: ffffffc0595b0670
> x23: 000000000080c6a0 x22: 002000080c6a0c43
> x21: 012000080c6a0c43 x20: 0000007fb5ccf000
> x19: ffffffbc1c2b7300 x18: 0000007fd7b45500
> x17: 0000000000412268 x16: 0000000000000004
> x15: 0000000000000002 x14: 0000000000000000
> x13: 0000000000003958 x12: 0000000000000048
> x11: 0000000000000013 x10: 00000000000000f0
> x9 : 0000000000000002 x8 : 0000007fb5ece000
> x7 : 0000000000000028 x6 : ffffffc00051b590
> x5 : 0000000000000670 x4 : 0020000000000c43
> x3 : ffffffc000000000 x2 : ffffffc0595b0000
> x1 : ffffffbc00000000 x0 : ffffffbc1c2b7300 Process layerscape (pid: 656, stack
> limit = 0xffffffc059294058)
> Stack: (0xffffffc059297bc0 to 0xffffffc059298000)
> 7bc0: 59297be0 ffffffc0 00102510 ffffffc0 59766d70 ffffffc0 ffffffc8 00000000
> 7be0: 59297c70 ffffffc0 002b51fc ffffffc0 595fd2c0 ffffffc0 596e78d8 ffffffc0
> 7c00: 00001000 00000000 0c6a0000 00000008 5969c4f8 ffffffc0 00000001 00000000
> 7c20: 595b1a00 ffffffc0 00000000 00000000 0047e558 ffffffc0 0047e548 ffffffc0
> 7c40: 59cff080 ffffffc0 b5ccefff 0000007f b5ccf000 0000007f 595eaff0 ffffffc0
> 7c60: f88569d2 ffffffff b5ccefff 0000007f 59297d00 ffffffc0 002b1cc4 ffffffc0
> 7c80: 595fd448 ffffffc0 b5cce000 0000007f 595fd440 ffffffc0 00000001 00000000
> 7ca0: 000000ff 00000000 59294000 ffffffc0 59cff080 ffffffc0 00000000 00000000
> 7cc0: 00000000 00000000 595fd420 ffffffc0 59297ce0 ffffffc0 595b1000 ffffffc0
> 7ce0: 0c6a1000 00000008 00001000 00000000 0047e5a0 ffffffc0 0047e580 ffffffc0
> 7d00: 59297d20 ffffffc0 00108968 ffffffc0 00000000 00000000 00000001 00000000
> 7d20: 59297da0 ffffffc0 00108e34 ffffffc0 00000007 00000000 000000ff 00000000
> 7d40: 595d36c0 ffffffc0 00000001 00000000 59cff080 ffffffc0 00001000 00000000
> 7d60: 00000001 00000000 b5cce000 0000007f 00000007 00000000 59294000 ffffffc0
> 7d80: 00000007 00000000 595fd2c0 ffffffc0 0080c6a0 00000000 595d36c0 ffffffc0
> 7da0: 59297e10 ffffffc0 000f9c40 ffffffc0 59cff0d8 ffffffc0 595d36c0 ffffffc0
> 7dc0: 00000000 00000000 0080c6a0 00000000 595d36c0 ffffffc0 00000015 00000000
> 7de0: 00000112 00000000 000000de 00000000 004ed000 ffffffc0 000f9c20 ffffffc0
> 7e00: 59297e68 ffffffc0 0080c6a0 00000000 59297e70 ffffffc0 00107508 ffffffc0
> 7e20: 00000001 00000000 00001000 00000000 59297e80 ffffffc0 0080c6a0 00000000
> 7e40: 00000001 00000000 00000003 00000000 00001000 00000000 00000000 00000000
> 7e60: 60000000 00000000 00000000 00000000 59297ec0 ffffffc0 00086d80 ffffffc0
> 7e80: 00000000 00000000 00000000 00000000 ffffffff ffffffff b5c2355c 0000007f
> 7ea0: 80000000 00000000 b5c1ffcc 0000007f 80000000 00000000 00000003 00000000
> 7ec0: d7b45720 0000007f 000839ec ffffffc0 00000000 00000000 00001000 00000000
> 7ee0: 00000003 00000000 00000001 00000000 00000005 00000000 0c6a0000 00000008
> 7f00: 00401884 00000000 00000000 00000000 000000de 00000000 b5ca35d0 0000007f
> 7f20: ffffffff 00000000 00000008 00000000 00000038 00000000 ffffffff ffffffff
> 7f40: 00000040 00000000 b5cd3028 0000007f b5c23548 0000007f 00412268 00000000
> 7f60: d7b45500 0000007f 00000000 00000000 00000000 00000000 004008c0 00000000
> 7f80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 7fa0: 00000000 00000000 00000000 00000000 00000000 00000000 d7b45720 0000007f
> 7fc0: 00400e38 00000000 d7b45720 0000007f b5c2355c 0000007f 80000000 00000000
> 7fe0: 00000000 00000000 000000de 00000000 00000000 00000000 00000000 00000000
> Call trace:
> [<ffffffc0000f9cac>] page_mapping+0x0/0x14 [<ffffffc000102510>]
> remap_pfn_range+0x1cc/0x324 [<ffffffc0002b51fc>]
> vfio_layerscape_mmap+0x22c/0x248 [<ffffffc0002b1cc4>]
> vfio_device_fops_mmap+0x20/0x30 [<ffffffc000108968>] mmap_region+0x320/0x538
> [<ffffffc000108e34>] do_mmap_pgoff+0x2b4/0x320 [<ffffffc0000f9c40>]
> vm_mmap_pgoff+0x60/0x90 [<ffffffc000107508>] SyS_mmap_pgoff+0x88/0xc4
> [<ffffffc000086d80>] sys_mmap+0x18/0x28
> Code: a8c17bfd d65f03c0 928002a0 17fffffd (f9400400) ---[ end trace
> 650769ec4955b30e ]---

Did you get the chance to look into this? What is your take for this patch or you want to suggest some other solution?

Thanks
-Bharat

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH] ARM64: Kernel managed pages are only flushed
  2014-03-12 14:41   ` Bharat.Bhushan at freescale.com
@ 2014-03-12 14:56     ` Will Deacon
  2014-03-12 16:03       ` Catalin Marinas
  0 siblings, 1 reply; 11+ messages in thread
From: Will Deacon @ 2014-03-12 14:56 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Mar 12, 2014 at 02:41:31PM +0000, Bharat.Bhushan at freescale.com wrote:
> Did you get the chance to look into this? What is your take for this patch
> or you want to suggest some other solution?

See my reply to Laura here:

  http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/238510.html

We *really* don't want executable device mappings.

Will

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH] ARM64: Kernel managed pages are only flushed
  2014-03-12 14:56     ` Will Deacon
@ 2014-03-12 16:03       ` Catalin Marinas
  2014-03-12 17:26         ` Catalin Marinas
  0 siblings, 1 reply; 11+ messages in thread
From: Catalin Marinas @ 2014-03-12 16:03 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Mar 12, 2014 at 02:56:53PM +0000, Will Deacon wrote:
> On Wed, Mar 12, 2014 at 02:41:31PM +0000, Bharat.Bhushan at freescale.com wrote:
> > Did you get the chance to look into this? What is your take for this patch
> > or you want to suggest some other solution?
> 
> See my reply to Laura here:
> 
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/238510.html
> 
> We *really* don't want executable device mappings.

/dev/mem mapping use pgprot_noncached() but I think we could generalise
any of the writecombine and dmacoherent mappings to XN like in the patch
below:

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index b524dcd17243..2d3cede62709 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -286,11 +286,11 @@ static inline int has_transparent_hugepage(void)
  * Mark the prot value as uncacheable and unbufferable.
  */
 #define pgprot_noncached(prot) \
-	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE))
+	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE) | PTE_PXN | PTE_UXN)
 #define pgprot_writecombine(prot) \
-	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC))
+	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
 #define pgprot_dmacoherent(prot) \
-	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC))
+	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
 #define __HAVE_PHYS_MEM_ACCESS_PROT
 struct file;
 extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,

-- 
Catalin

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH] ARM64: Kernel managed pages are only flushed
  2014-03-12 16:03       ` Catalin Marinas
@ 2014-03-12 17:26         ` Catalin Marinas
  2014-03-12 20:12           ` Laura Abbott
                             ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Catalin Marinas @ 2014-03-12 17:26 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Mar 12, 2014 at 04:03:40PM +0000, Catalin Marinas wrote:
> On Wed, Mar 12, 2014 at 02:56:53PM +0000, Will Deacon wrote:
> > On Wed, Mar 12, 2014 at 02:41:31PM +0000, Bharat.Bhushan at freescale.com wrote:
> > > Did you get the chance to look into this? What is your take for this patch
> > > or you want to suggest some other solution?
> > 
> > See my reply to Laura here:
> > 
> >   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/238510.html
> > 
> > We *really* don't want executable device mappings.
> 
> /dev/mem mapping use pgprot_noncached() but I think we could generalise
> any of the writecombine and dmacoherent mappings to XN like in the patch
> below:
> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index b524dcd17243..2d3cede62709 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -286,11 +286,11 @@ static inline int has_transparent_hugepage(void)
>   * Mark the prot value as uncacheable and unbufferable.
>   */
>  #define pgprot_noncached(prot) \
> -	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE))
> +	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE) | PTE_PXN | PTE_UXN)
>  #define pgprot_writecombine(prot) \
> -	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC))
> +	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
>  #define pgprot_dmacoherent(prot) \
> -	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC))
> +	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
>  #define __HAVE_PHYS_MEM_ACCESS_PROT
>  struct file;
>  extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,

And one more patch as suggested by Steve Capper. Both would be needed.

-------------8<----------------------

>From 31d84855d71778e4a0f615f61ab836be3a70a58b Mon Sep 17 00:00:00 2001
From: Catalin Marinas <catalin.marinas@arm.com>
Date: Wed, 12 Mar 2014 16:28:09 +0000
Subject: [PATCH] arm64: Do not synchronise I and D caches for special ptes

Special pte mappings are not intended to be executable and do not even
have an associated struct page. This patch ensures that we do not call
__sync_icache_dcache() on such ptes.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Steve Capper <Steve.Capper@arm.com>
---
 arch/arm64/include/asm/pgtable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 2d3cede62709..72c9ac38cdd9 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -199,7 +199,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
 			      pte_t *ptep, pte_t pte)
 {
 	if (pte_valid_user(pte)) {
-		if (pte_exec(pte))
+		if (!pte_special(pte) && pte_exec(pte))
 			__sync_icache_dcache(pte, addr);
 		if (pte_dirty(pte) && pte_write(pte))
 			pte_val(pte) &= ~PTE_RDONLY;

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH] ARM64: Kernel managed pages are only flushed
  2014-03-12 17:26         ` Catalin Marinas
@ 2014-03-12 20:12           ` Laura Abbott
  2014-03-13 11:00           ` Bharat.Bhushan at freescale.com
  2014-03-26  3:16           ` Bharat.Bhushan at freescale.com
  2 siblings, 0 replies; 11+ messages in thread
From: Laura Abbott @ 2014-03-12 20:12 UTC (permalink / raw)
  To: linux-arm-kernel

On 3/12/2014 10:26 AM, Catalin Marinas wrote:
> On Wed, Mar 12, 2014 at 04:03:40PM +0000, Catalin Marinas wrote:
>> On Wed, Mar 12, 2014 at 02:56:53PM +0000, Will Deacon wrote:
>>> On Wed, Mar 12, 2014 at 02:41:31PM +0000, Bharat.Bhushan at freescale.com wrote:
>>>> Did you get the chance to look into this? What is your take for this patch
>>>> or you want to suggest some other solution?
>>>
>>> See my reply to Laura here:
>>>
>>>    http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/238510.html
>>>
>>> We *really* don't want executable device mappings.
>>
>> /dev/mem mapping use pgprot_noncached() but I think we could generalise
>> any of the writecombine and dmacoherent mappings to XN like in the patch
>> below:
>>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index b524dcd17243..2d3cede62709 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -286,11 +286,11 @@ static inline int has_transparent_hugepage(void)
>>    * Mark the prot value as uncacheable and unbufferable.
>>    */
>>   #define pgprot_noncached(prot) \
>> -	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE))
>> +	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE) | PTE_PXN | PTE_UXN)
>>   #define pgprot_writecombine(prot) \
>> -	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC))
>> +	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
>>   #define pgprot_dmacoherent(prot) \
>> -	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC))
>> +	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
>>   #define __HAVE_PHYS_MEM_ACCESS_PROT
>>   struct file;
>>   extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
>
> And one more patch as suggested by Steve Capper. Both would be needed.
>
> -------------8<----------------------
>
>  From 31d84855d71778e4a0f615f61ab836be3a70a58b Mon Sep 17 00:00:00 2001
> From: Catalin Marinas <catalin.marinas@arm.com>
> Date: Wed, 12 Mar 2014 16:28:09 +0000
> Subject: [PATCH] arm64: Do not synchronise I and D caches for special ptes
>
> Special pte mappings are not intended to be executable and do not even
> have an associated struct page. This patch ensures that we do not call
> __sync_icache_dcache() on such ptes.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Reported-by: Steve Capper <Steve.Capper@arm.com>
> ---
>   arch/arm64/include/asm/pgtable.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 2d3cede62709..72c9ac38cdd9 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -199,7 +199,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
>   			      pte_t *ptep, pte_t pte)
>   {
>   	if (pte_valid_user(pte)) {
> -		if (pte_exec(pte))
> +		if (!pte_special(pte) && pte_exec(pte))
>   			__sync_icache_dcache(pte, addr);
>   		if (pte_dirty(pte) && pte_write(pte))
>   			pte_val(pte) &= ~PTE_RDONLY;
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Both let my simple test case pass (remap_pfn_range on io memory).
You can add my Tested-by to both patches.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH] ARM64: Kernel managed pages are only flushed
  2014-03-12 17:26         ` Catalin Marinas
  2014-03-12 20:12           ` Laura Abbott
@ 2014-03-13 11:00           ` Bharat.Bhushan at freescale.com
  2014-03-26  3:16           ` Bharat.Bhushan at freescale.com
  2 siblings, 0 replies; 11+ messages in thread
From: Bharat.Bhushan at freescale.com @ 2014-03-13 11:00 UTC (permalink / raw)
  To: linux-arm-kernel



> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas at arm.com]
> Sent: Wednesday, March 12, 2014 10:57 PM
> To: Will Deacon
> Cc: Bhushan Bharat-R65777; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH] ARM64: Kernel managed pages are only flushed
> 
> On Wed, Mar 12, 2014 at 04:03:40PM +0000, Catalin Marinas wrote:
> > On Wed, Mar 12, 2014 at 02:56:53PM +0000, Will Deacon wrote:
> > > On Wed, Mar 12, 2014 at 02:41:31PM +0000, Bharat.Bhushan at freescale.com
> wrote:
> > > > Did you get the chance to look into this? What is your take for
> > > > this patch or you want to suggest some other solution?
> > >
> > > See my reply to Laura here:
> > >
> > >
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/238
> > > 510.html
> > >
> > > We *really* don't want executable device mappings.
> >
> > /dev/mem mapping use pgprot_noncached() but I think we could
> > generalise any of the writecombine and dmacoherent mappings to XN like
> > in the patch
> > below:
> >
> > diff --git a/arch/arm64/include/asm/pgtable.h
> > b/arch/arm64/include/asm/pgtable.h
> > index b524dcd17243..2d3cede62709 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -286,11 +286,11 @@ static inline int has_transparent_hugepage(void)
> >   * Mark the prot value as uncacheable and unbufferable.
> >   */
> >  #define pgprot_noncached(prot) \
> > -	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE))
> > +	__pgprot_modify(prot, PTE_ATTRINDX_MASK,
> > +PTE_ATTRINDX(MT_DEVICE_nGnRnE) | PTE_PXN | PTE_UXN)
> >  #define pgprot_writecombine(prot) \
> > -	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC))
> > +	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC)
> > +| PTE_PXN | PTE_UXN)
> >  #define pgprot_dmacoherent(prot) \
> > -	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC))
> > +	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC)
> > +| PTE_PXN | PTE_UXN)
> >  #define __HAVE_PHYS_MEM_ACCESS_PROT
> >  struct file;
> >  extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long
> > pfn,
> 
> And one more patch as suggested by Steve Capper. Both would be needed.
> 
> -------------8<----------------------
> 
> From 31d84855d71778e4a0f615f61ab836be3a70a58b Mon Sep 17 00:00:00 2001
> From: Catalin Marinas <catalin.marinas@arm.com>
> Date: Wed, 12 Mar 2014 16:28:09 +0000
> Subject: [PATCH] arm64: Do not synchronise I and D caches for special ptes
> 
> Special pte mappings are not intended to be executable and do not even have an
> associated struct page. This patch ensures that we do not call
> __sync_icache_dcache() on such ptes.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Reported-by: Steve Capper <Steve.Capper@arm.com>
> ---
>  arch/arm64/include/asm/pgtable.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 2d3cede62709..72c9ac38cdd9 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -199,7 +199,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned
> long addr,
>  			      pte_t *ptep, pte_t pte)
>  {
>  	if (pte_valid_user(pte)) {
> -		if (pte_exec(pte))
> +		if (!pte_special(pte) && pte_exec(pte))
>  			__sync_icache_dcache(pte, addr);
>  		if (pte_dirty(pte) && pte_write(pte))
>  			pte_val(pte) &= ~PTE_RDONLY;
> 

Tested-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>

Thanks
-Bharat

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH] ARM64: Kernel managed pages are only flushed
  2014-03-12 17:26         ` Catalin Marinas
  2014-03-12 20:12           ` Laura Abbott
  2014-03-13 11:00           ` Bharat.Bhushan at freescale.com
@ 2014-03-26  3:16           ` Bharat.Bhushan at freescale.com
  2014-03-27 10:55             ` Catalin Marinas
  2 siblings, 1 reply; 11+ messages in thread
From: Bharat.Bhushan at freescale.com @ 2014-03-26  3:16 UTC (permalink / raw)
  To: linux-arm-kernel



> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas at arm.com]
> Sent: Wednesday, March 12, 2014 10:57 PM
> To: Will Deacon
> Cc: Bhushan Bharat-R65777; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH] ARM64: Kernel managed pages are only flushed
> 
> On Wed, Mar 12, 2014 at 04:03:40PM +0000, Catalin Marinas wrote:
> > On Wed, Mar 12, 2014 at 02:56:53PM +0000, Will Deacon wrote:
> > > On Wed, Mar 12, 2014 at 02:41:31PM +0000, Bharat.Bhushan at freescale.com
> wrote:
> > > > Did you get the chance to look into this? What is your take for
> > > > this patch or you want to suggest some other solution?
> > >
> > > See my reply to Laura here:
> > >
> > >
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/238
> > > 510.html
> > >
> > > We *really* don't want executable device mappings.
> >
> > /dev/mem mapping use pgprot_noncached() but I think we could
> > generalise any of the writecombine and dmacoherent mappings to XN like
> > in the patch
> > below:
> >
> > diff --git a/arch/arm64/include/asm/pgtable.h
> > b/arch/arm64/include/asm/pgtable.h
> > index b524dcd17243..2d3cede62709 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -286,11 +286,11 @@ static inline int has_transparent_hugepage(void)
> >   * Mark the prot value as uncacheable and unbufferable.
> >   */
> >  #define pgprot_noncached(prot) \
> > -	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE))
> > +	__pgprot_modify(prot, PTE_ATTRINDX_MASK,
> > +PTE_ATTRINDX(MT_DEVICE_nGnRnE) | PTE_PXN | PTE_UXN)
> >  #define pgprot_writecombine(prot) \
> > -	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC))
> > +	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC)
> > +| PTE_PXN | PTE_UXN)
> >  #define pgprot_dmacoherent(prot) \
> > -	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC))
> > +	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC)
> > +| PTE_PXN | PTE_UXN)
> >  #define __HAVE_PHYS_MEM_ACCESS_PROT
> >  struct file;
> >  extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long
> > pfn,
> 
> And one more patch as suggested by Steve Capper. Both would be needed.
> 
> -------------8<----------------------
> 
> From 31d84855d71778e4a0f615f61ab836be3a70a58b Mon Sep 17 00:00:00 2001
> From: Catalin Marinas <catalin.marinas@arm.com>
> Date: Wed, 12 Mar 2014 16:28:09 +0000
> Subject: [PATCH] arm64: Do not synchronise I and D caches for special ptes
> 
> Special pte mappings are not intended to be executable and do not even have an
> associated struct page. This patch ensures that we do not call
> __sync_icache_dcache() on such ptes.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Reported-by: Steve Capper <Steve.Capper@arm.com>
> ---
>  arch/arm64/include/asm/pgtable.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 2d3cede62709..72c9ac38cdd9 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -199,7 +199,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned
> long addr,
>  			      pte_t *ptep, pte_t pte)
>  {
>  	if (pte_valid_user(pte)) {
> -		if (pte_exec(pte))
> +		if (!pte_special(pte) && pte_exec(pte))
>  			__sync_icache_dcache(pte, addr);
>  		if (pte_dirty(pte) && pte_write(pte))
>  			pte_val(pte) &= ~PTE_RDONLY;

Hi Catalin,

These patches are not yet posted if I have not missed. Also a little bit of confusion, will you be posting these patches or you want me/someone to post these couple of patches? I am assuming you will be posting these patches, if so any idea when we can see these patches?

Thanks
-Bharat
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH] ARM64: Kernel managed pages are only flushed
  2014-03-26  3:16           ` Bharat.Bhushan at freescale.com
@ 2014-03-27 10:55             ` Catalin Marinas
  0 siblings, 0 replies; 11+ messages in thread
From: Catalin Marinas @ 2014-03-27 10:55 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Mar 26, 2014 at 03:16:29AM +0000, Bharat.Bhushan at freescale.com wrote:
> > From 31d84855d71778e4a0f615f61ab836be3a70a58b Mon Sep 17 00:00:00 2001
> > From: Catalin Marinas <catalin.marinas@arm.com>
> > Date: Wed, 12 Mar 2014 16:28:09 +0000
> > Subject: [PATCH] arm64: Do not synchronise I and D caches for special ptes
> > 
> > Special pte mappings are not intended to be executable and do not even have an
> > associated struct page. This patch ensures that we do not call
> > __sync_icache_dcache() on such ptes.
> > 
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Reported-by: Steve Capper <Steve.Capper@arm.com>
> > ---
> >  arch/arm64/include/asm/pgtable.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> > index 2d3cede62709..72c9ac38cdd9 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -199,7 +199,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned
> > long addr,
> >  			      pte_t *ptep, pte_t pte)
> >  {
> >  	if (pte_valid_user(pte)) {
> > -		if (pte_exec(pte))
> > +		if (!pte_special(pte) && pte_exec(pte))
> >  			__sync_icache_dcache(pte, addr);
> >  		if (pte_dirty(pte) && pte_write(pte))
> >  			pte_val(pte) &= ~PTE_RDONLY;
> 
> These patches are not yet posted if I have not missed. Also a little
> bit of confusion, will you be posting these patches or you want
> me/someone to post these couple of patches? I am assuming you will be
> posting these patches, if so any idea when we can see these patches?

I added them in the arm64 for-next/core branch (on git.kernel.org) and
they are in linux-next (with a cc stable, though I didn't bother sending
a late -rc pull request for them).

-- 
Catalin

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2014-03-27 10:55 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-05 11:20 [PATCH] ARM64: Kernel managed pages are only flushed Bharat Bhushan
2014-03-06  6:53 ` Catalin Marinas
2014-03-06  9:33   ` Bharat.Bhushan at freescale.com
2014-03-12 14:41   ` Bharat.Bhushan at freescale.com
2014-03-12 14:56     ` Will Deacon
2014-03-12 16:03       ` Catalin Marinas
2014-03-12 17:26         ` Catalin Marinas
2014-03-12 20:12           ` Laura Abbott
2014-03-13 11:00           ` Bharat.Bhushan at freescale.com
2014-03-26  3:16           ` Bharat.Bhushan at freescale.com
2014-03-27 10:55             ` Catalin Marinas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).