* [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).