| Message ID | 20150120140546.DDCB8D4@black.fi.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jan 20, 2015 at 12:05 PM, Kirill A. Shutemov <kirill.shutemov@linux.intel.com> wrote: > Russell King - ARM Linux wrote: >> On Tue, Jan 20, 2015 at 02:16:43AM +0200, Kirill A. Shutemov wrote: >> > Better option would be converting 2-lvl ARM configuration to >> > <asm-generic/pgtable-nopmd.h>, but I'm not sure if it's possible. >> >> Well, IMHO the folded approach in asm-generic was done the wrong way >> which barred ARM from ever using it. > > Okay, I see. > > Regarding the topic bug. Completely untested patch is below. Could anybody > check if it helps? Yes, it helps. Now I can boot mx6 running linux-next 20150120 with your patch applied.
On Tue, Jan 20, 2015 at 12:50:59PM -0200, Fabio Estevam wrote: > On Tue, Jan 20, 2015 at 12:05 PM, Kirill A. Shutemov > <kirill.shutemov@linux.intel.com> wrote: > > Russell King - ARM Linux wrote: > >> On Tue, Jan 20, 2015 at 02:16:43AM +0200, Kirill A. Shutemov wrote: > >> > Better option would be converting 2-lvl ARM configuration to > >> > <asm-generic/pgtable-nopmd.h>, but I'm not sure if it's possible. > >> > >> Well, IMHO the folded approach in asm-generic was done the wrong way > >> which barred ARM from ever using it. > > > > Okay, I see. > > > > Regarding the topic bug. Completely untested patch is below. Could anybody > > check if it helps? > > Yes, it helps. Now I can boot mx6 running linux-next 20150120 with > your patch applied. worked fine here too with AM437x SK, AM437x IDK and BeagleBoneBlack. thanks
On 16:05-20150120, Kirill A. Shutemov wrote: > Russell King - ARM Linux wrote: > > On Tue, Jan 20, 2015 at 02:16:43AM +0200, Kirill A. Shutemov wrote: > > > Better option would be converting 2-lvl ARM configuration to > > > <asm-generic/pgtable-nopmd.h>, but I'm not sure if it's possible. > > > > Well, IMHO the folded approach in asm-generic was done the wrong way > > which barred ARM from ever using it. > > Okay, I see. > > Regarding the topic bug. Completely untested patch is below. Could anybody > check if it helps? > > From 34b9182d08ef2b541829e305fcc91ef1d26b27ea Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> > Date: Tue, 20 Jan 2015 15:47:22 +0200 > Subject: [PATCH] arm: define __PAGETABLE_PMD_FOLDED for !LPAE > > ARM uses custom implementation of PMD folding in 2-level page table case. > Generic code expects to see __PAGETABLE_PMD_FOLDED to be defined if PMD is > folded, but ARM doesn't do this. Let's fix it. > > Defining __PAGETABLE_PMD_FOLDED will drop out unused __pmd_alloc(). > It also fixes problems with recently-introduced pmd accounting on ARM > without LPAE. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Reported-by: Nishanth Menon <nm@ti.com> > --- > arch/arm/include/asm/pgtable-2level.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h > index bcc5e300413f..bfd662e49a25 100644 > --- a/arch/arm/include/asm/pgtable-2level.h > +++ b/arch/arm/include/asm/pgtable-2level.h > @@ -10,6 +10,8 @@ > #ifndef _ASM_PGTABLE_2LEVEL_H > #define _ASM_PGTABLE_2LEVEL_H > > +#define __PAGETABLE_PMD_FOLDED > + > /* > * Hardware-wise, we have a two level page table structure, where the first > * level has 4096 entries, and the second level has 256 entries. Each entry > -- > 2.1.4 Above helps the TI platforms 1: am335x-evm: BOOT: PASS: am335x-evm.txt 2: am335x-sk: BOOT: PASS: am335x-sk.txt 3: am3517-evm: BOOT: PASS: am3517-evm.txt 4: am37x-evm: BOOT: PASS: am37x-evm.txt 5: am437x-sk: BOOT: PASS: am437x-sk.txt 6: am43xx-epos: BOOT: PASS: am43xx-epos.txt 7: am43xx-gpevm: BOOT: PASS: am43xx-gpevm.txt 8: BeagleBoard-X15(am57xx-evm): BOOT: PASS: am57xx-evm.txt 9: BeagleBoard-XM: BOOT: PASS: beagleboard.txt 10: beagleboard-vanilla: BOOT: PASS: beagleboard-vanilla.txt 11: beaglebone-black: BOOT: PASS: beaglebone-black.txt 12: beaglebone: BOOT: PASS: beaglebone.txt 13: craneboard: BOOT: PASS: craneboard.txt 14: dra72x-evm: BOOT: PASS: dra72x-evm.txt 15: dra7xx-evm: BOOT: PASS: dra7xx-evm.txt 16: OMAP3430-Labrador(LDP): BOOT: PASS: ldp.txt 17: n900: BOOT: FAIL: n900.txt (legacy issue with my farm) 18: omap5-evm: BOOT: PASS: omap5-evm.txt 19: pandaboard-es: BOOT: PASS: pandaboard-es.txt 20: pandaboard-vanilla: BOOT: PASS: pandaboard-vanilla.txt 21: sdp2430: BOOT: PASS: sdp2430.txt 22: sdp3430: BOOT: PASS: sdp3430.txt 23: sdp4430: BOOT: PASS: sdp4430.txt TOTAL = 23 boards, Booted Boards = 22, No Boot boards = 1 please feel free to add my Tested-by: Nishanth Menon <nm@ti.com>
On 01/20/2015 04:05 PM, Kirill A. Shutemov wrote: > Russell King - ARM Linux wrote: >> On Tue, Jan 20, 2015 at 02:16:43AM +0200, Kirill A. Shutemov wrote: >>> Better option would be converting 2-lvl ARM configuration to >>> <asm-generic/pgtable-nopmd.h>, but I'm not sure if it's possible. >> >> Well, IMHO the folded approach in asm-generic was done the wrong way >> which barred ARM from ever using it. > > Okay, I see. > > Regarding the topic bug. Completely untested patch is below. Could anybody > check if it helps? > > From 34b9182d08ef2b541829e305fcc91ef1d26b27ea Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> > Date: Tue, 20 Jan 2015 15:47:22 +0200 > Subject: [PATCH] arm: define __PAGETABLE_PMD_FOLDED for !LPAE > > ARM uses custom implementation of PMD folding in 2-level page table case. > Generic code expects to see __PAGETABLE_PMD_FOLDED to be defined if PMD is > folded, but ARM doesn't do this. Let's fix it. > > Defining __PAGETABLE_PMD_FOLDED will drop out unused __pmd_alloc(). > It also fixes problems with recently-introduced pmd accounting on ARM > without LPAE. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Reported-by: Nishanth Menon <nm@ti.com> > --- > arch/arm/include/asm/pgtable-2level.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h > index bcc5e300413f..bfd662e49a25 100644 > --- a/arch/arm/include/asm/pgtable-2level.h > +++ b/arch/arm/include/asm/pgtable-2level.h > @@ -10,6 +10,8 @@ > #ifndef _ASM_PGTABLE_2LEVEL_H > #define _ASM_PGTABLE_2LEVEL_H > > +#define __PAGETABLE_PMD_FOLDED > + > /* > * Hardware-wise, we have a two level page table structure, where the first > * level has 4096 entries, and the second level has 256 entries. Each entry > Among other boards I have my daVinci board (OMAP-L138-EVM) boots fine with this patch. Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
2015-01-20 15:05 GMT+01:00 Kirill A. Shutemov <kirill.shutemov@linux.intel.com>: > Russell King - ARM Linux wrote: >> On Tue, Jan 20, 2015 at 02:16:43AM +0200, Kirill A. Shutemov wrote: >> > Better option would be converting 2-lvl ARM configuration to >> > <asm-generic/pgtable-nopmd.h>, but I'm not sure if it's possible. >> >> Well, IMHO the folded approach in asm-generic was done the wrong way >> which barred ARM from ever using it. > > Okay, I see. > > Regarding the topic bug. Completely untested patch is below. Could anybody > check if it helps? > > From 34b9182d08ef2b541829e305fcc91ef1d26b27ea Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> > Date: Tue, 20 Jan 2015 15:47:22 +0200 > Subject: [PATCH] arm: define __PAGETABLE_PMD_FOLDED for !LPAE > > ARM uses custom implementation of PMD folding in 2-level page table case. > Generic code expects to see __PAGETABLE_PMD_FOLDED to be defined if PMD is > folded, but ARM doesn't do this. Let's fix it. > > Defining __PAGETABLE_PMD_FOLDED will drop out unused __pmd_alloc(). > It also fixes problems with recently-introduced pmd accounting on ARM > without LPAE. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Reported-by: Nishanth Menon <nm@ti.com> > --- > arch/arm/include/asm/pgtable-2level.h | 2 ++ > 1 file changed, 2 insertions(+) Helps for this issue on Exynos 4412 (Trats2) and Exynos 5420 (Arndale Octa): Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Off-topic: "Using smp_processor_id() in preemptible" still screams [1] [1] https://lkml.org/lkml/2015/1/20/162 Best regards, Krzysztof
On 16:05-20150120, Kirill A. Shutemov wrote: [..] > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Reported-by: Nishanth Menon <nm@ti.com> Just to close on this thread: https://github.com/nmenon/kernel-test-logs/tree/next-20150123 looks good and back to old status. Thank you folks for all the help.
Hi, On 23 January 2015 at 09:27, Nishanth Menon <nm@ti.com> wrote: > On 16:05-20150120, Kirill A. Shutemov wrote: > [..] >> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> >> Reported-by: Nishanth Menon <nm@ti.com> > Just to close on this thread: > https://github.com/nmenon/kernel-test-logs/tree/next-20150123 looks good > and back to old status. Thank you folks for all the help. I just reviewed the boot logs for next-20150123 and there still seems to be a related issue. I've been boot testing multi_v7_defconfig+CONFIG_ARM_LPAE=y kernel configurations which still seem broken. For example here are two boots with exynos5250-arndale, one with multi_v7_defconfig+CONFIG_ARM_LPAE=y [1] and the other with multi_v7_defconfig[2]. You can see the kernel configurations with CONFIG_ARM_LPAE=y show the splat: [ 14.605950] ------------[ cut here ]------------ [ 14.609163] WARNING: CPU: 1 PID: 63 at ../mm/mmap.c:2858 exit_mmap+0x1b8/0x224() [ 14.616548] Modules linked in: [ 14.619553] CPU: 1 PID: 63 Comm: init Not tainted 3.19.0-rc5-next-20150123 #1 [ 14.626713] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 14.632830] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 14.640473] [] (show_stack) from [] (dump_stack+0x78/0x94) [ 14.647678] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0) [ 14.655744] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [ 14.664510] [] (warn_slowpath_null) from [] (exit_mmap+0x1b8/0x224) [ 14.672497] [] (exit_mmap) from [] (mmput+0x40/0xf8) [ 14.679180] [] (mmput) from [] (flush_old_exec+0x328/0x604) [ 14.686471] [] (flush_old_exec) from [] (load_elf_binary+0x26c/0x11f4) [ 14.694715] [] (load_elf_binary) from [] (search_binary_handler+0x98/0x244) [ 14.703395] [] (search_binary_handler) from [] (do_execveat_common+0x4dc/0x5bc) [ 14.712421] [] (do_execveat_common) from [] (do_execve+0x28/0x30) [ 14.720235] [] (do_execve) from [] (ret_fast_syscall+0x0/0x34) [ 14.727782] ---[ end trace 5e3ca48b454c7e0a ]--- [ 14.733758] ------------[ cut here ]------------ Has anyone else tested with CONFIG_ARM_LPAE=y that can confirm my findings? > -- > Regards, > Nishanth Menon > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel [1] http://storage.kernelci.org/next/next-20150123/arm-multi_v7_defconfig+CONFIG_ARM_LPAE=y/lab-tbaker/boot-exynos5250-arndale.html [2] http://storage.kernelci.org/next/next-20150123/arm-multi_v7_defconfig/lab-tbaker/boot-exynos5250-arndale.html Cheers, Tyler
On 09:39-20150123, Tyler Baker wrote: > Hi, > > On 23 January 2015 at 09:27, Nishanth Menon <nm@ti.com> wrote: > > On 16:05-20150120, Kirill A. Shutemov wrote: > > [..] > >> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > >> Reported-by: Nishanth Menon <nm@ti.com> > > Just to close on this thread: > > https://github.com/nmenon/kernel-test-logs/tree/next-20150123 looks good > > and back to old status. Thank you folks for all the help. > > I just reviewed the boot logs for next-20150123 and there still seems > to be a related issue. I've been boot testing > multi_v7_defconfig+CONFIG_ARM_LPAE=y kernel configurations which still > seem broken. > > For example here are two boots with exynos5250-arndale, one with > multi_v7_defconfig+CONFIG_ARM_LPAE=y [1] and the other with > multi_v7_defconfig[2]. You can see the kernel configurations with > CONFIG_ARM_LPAE=y show the splat: > > [ 14.605950] ------------[ cut here ]------------ > [ 14.609163] WARNING: CPU: 1 PID: 63 at ../mm/mmap.c:2858 > exit_mmap+0x1b8/0x224() > [ 14.616548] Modules linked in: > [ 14.619553] CPU: 1 PID: 63 Comm: init Not tainted 3.19.0-rc5-next-20150123 #1 > [ 14.626713] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [ 14.632830] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [ 14.640473] [] (show_stack) from [] (dump_stack+0x78/0x94) > [ 14.647678] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0) > [ 14.655744] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) > [ 14.664510] [] (warn_slowpath_null) from [] (exit_mmap+0x1b8/0x224) > [ 14.672497] [] (exit_mmap) from [] (mmput+0x40/0xf8) > [ 14.679180] [] (mmput) from [] (flush_old_exec+0x328/0x604) > [ 14.686471] [] (flush_old_exec) from [] (load_elf_binary+0x26c/0x11f4) > [ 14.694715] [] (load_elf_binary) from [] (search_binary_handler+0x98/0x244) > [ 14.703395] [] (search_binary_handler) from [] > (do_execveat_common+0x4dc/0x5bc) > [ 14.712421] [] (do_execveat_common) from [] (do_execve+0x28/0x30) > [ 14.720235] [] (do_execve) from [] (ret_fast_syscall+0x0/0x34) > [ 14.727782] ---[ end trace 5e3ca48b454c7e0a ]--- > [ 14.733758] ------------[ cut here ]------------ > > Has anyone else tested with CONFIG_ARM_LPAE=y that can confirm my findings? Uggh... I missed since i was looking at non LPAE omap2plus_defconfig. Dual A15 OMAP5432 with multi_v7_defconfig + CONFIG_ARM_LPAE=y https://github.com/nmenon/kernel-test-logs/blob/next-20150123/multi_lpae_defconfig/omap5-evm.txt Dual A15 DRA7/AM572x with same configuration as above. https://raw.githubusercontent.com/nmenon/kernel-test-logs/next-20150123/multi_lpae_defconfig/dra7xx-evm.txt https://github.com/nmenon/kernel-test-logs/blob/next-20150123/multi_lpae_defconfig/am57xx-evm.txt Single A15 DRA72 with same configuration as above: https://raw.githubusercontent.com/nmenon/kernel-test-logs/next-20150123/multi_lpae_defconfig/dra72x-evm.txt You are right. the issue re-appears with LPAE on :( Apologies on missing that. > > > > -- > > Regards, > > Nishanth Menon > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > [1] http://storage.kernelci.org/next/next-20150123/arm-multi_v7_defconfig+CONFIG_ARM_LPAE=y/lab-tbaker/boot-exynos5250-arndale.html > > [2] http://storage.kernelci.org/next/next-20150123/arm-multi_v7_defconfig/lab-tbaker/boot-exynos5250-arndale.html > > Cheers, > > Tyler
On Fri, Jan 23, 2015 at 12:37:06PM -0600, Nishanth Menon wrote: > On 09:39-20150123, Tyler Baker wrote: > > Hi, > > > > On 23 January 2015 at 09:27, Nishanth Menon <nm@ti.com> wrote: > > > On 16:05-20150120, Kirill A. Shutemov wrote: > > > [..] > > >> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > >> Reported-by: Nishanth Menon <nm@ti.com> > > > Just to close on this thread: > > > https://github.com/nmenon/kernel-test-logs/tree/next-20150123 looks good > > > and back to old status. Thank you folks for all the help. > > > > I just reviewed the boot logs for next-20150123 and there still seems > > to be a related issue. I've been boot testing > > multi_v7_defconfig+CONFIG_ARM_LPAE=y kernel configurations which still > > seem broken. > > > > For example here are two boots with exynos5250-arndale, one with > > multi_v7_defconfig+CONFIG_ARM_LPAE=y [1] and the other with > > multi_v7_defconfig[2]. You can see the kernel configurations with > > CONFIG_ARM_LPAE=y show the splat: > > > > [ 14.605950] ------------[ cut here ]------------ > > [ 14.609163] WARNING: CPU: 1 PID: 63 at ../mm/mmap.c:2858 > > exit_mmap+0x1b8/0x224() > > [ 14.616548] Modules linked in: > > [ 14.619553] CPU: 1 PID: 63 Comm: init Not tainted 3.19.0-rc5-next-20150123 #1 > > [ 14.626713] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > > [ 14.632830] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > [ 14.640473] [] (show_stack) from [] (dump_stack+0x78/0x94) > > [ 14.647678] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0) > > [ 14.655744] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) > > [ 14.664510] [] (warn_slowpath_null) from [] (exit_mmap+0x1b8/0x224) > > [ 14.672497] [] (exit_mmap) from [] (mmput+0x40/0xf8) > > [ 14.679180] [] (mmput) from [] (flush_old_exec+0x328/0x604) > > [ 14.686471] [] (flush_old_exec) from [] (load_elf_binary+0x26c/0x11f4) > > [ 14.694715] [] (load_elf_binary) from [] (search_binary_handler+0x98/0x244) > > [ 14.703395] [] (search_binary_handler) from [] > > (do_execveat_common+0x4dc/0x5bc) > > [ 14.712421] [] (do_execveat_common) from [] (do_execve+0x28/0x30) > > [ 14.720235] [] (do_execve) from [] (ret_fast_syscall+0x0/0x34) > > [ 14.727782] ---[ end trace 5e3ca48b454c7e0a ]--- > > [ 14.733758] ------------[ cut here ]------------ > > > > Has anyone else tested with CONFIG_ARM_LPAE=y that can confirm my findings? > Uggh... I missed since i was looking at non LPAE omap2plus_defconfig. > > Dual A15 OMAP5432 with multi_v7_defconfig + CONFIG_ARM_LPAE=y > https://github.com/nmenon/kernel-test-logs/blob/next-20150123/multi_lpae_defconfig/omap5-evm.txt > > Dual A15 DRA7/AM572x with same configuration as above. > https://raw.githubusercontent.com/nmenon/kernel-test-logs/next-20150123/multi_lpae_defconfig/dra7xx-evm.txt > https://github.com/nmenon/kernel-test-logs/blob/next-20150123/multi_lpae_defconfig/am57xx-evm.txt > > Single A15 DRA72 with same configuration as above: > https://raw.githubusercontent.com/nmenon/kernel-test-logs/next-20150123/multi_lpae_defconfig/dra72x-evm.txt > > You are right. the issue re-appears with LPAE on :( > Apologies on missing that. Guys, could you instrument mm_{inc,dec}_nr_pmds() with dump_stack() + printk() of the counter and add printk() on mmap_exit() then run a simple program which triggers the issue?
On 22:22-20150123, Kirill A. Shutemov wrote: > On Fri, Jan 23, 2015 at 12:37:06PM -0600, Nishanth Menon wrote: > > On 09:39-20150123, Tyler Baker wrote: > > > Hi, > > > > > > On 23 January 2015 at 09:27, Nishanth Menon <nm@ti.com> wrote: > > > > On 16:05-20150120, Kirill A. Shutemov wrote: > > > > [..] > > > >> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > > >> Reported-by: Nishanth Menon <nm@ti.com> > > > > Just to close on this thread: > > > > https://github.com/nmenon/kernel-test-logs/tree/next-20150123 looks good > > > > and back to old status. Thank you folks for all the help. > > > > > > I just reviewed the boot logs for next-20150123 and there still seems > > > to be a related issue. I've been boot testing > > > multi_v7_defconfig+CONFIG_ARM_LPAE=y kernel configurations which still > > > seem broken. > > > > > > For example here are two boots with exynos5250-arndale, one with > > > multi_v7_defconfig+CONFIG_ARM_LPAE=y [1] and the other with > > > multi_v7_defconfig[2]. You can see the kernel configurations with > > > CONFIG_ARM_LPAE=y show the splat: > > > > > > [ 14.605950] ------------[ cut here ]------------ > > > [ 14.609163] WARNING: CPU: 1 PID: 63 at ../mm/mmap.c:2858 > > > exit_mmap+0x1b8/0x224() > > > [ 14.616548] Modules linked in: > > > [ 14.619553] CPU: 1 PID: 63 Comm: init Not tainted 3.19.0-rc5-next-20150123 #1 > > > [ 14.626713] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > > > [ 14.632830] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > > [ 14.640473] [] (show_stack) from [] (dump_stack+0x78/0x94) > > > [ 14.647678] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0) > > > [ 14.655744] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) > > > [ 14.664510] [] (warn_slowpath_null) from [] (exit_mmap+0x1b8/0x224) > > > [ 14.672497] [] (exit_mmap) from [] (mmput+0x40/0xf8) > > > [ 14.679180] [] (mmput) from [] (flush_old_exec+0x328/0x604) > > > [ 14.686471] [] (flush_old_exec) from [] (load_elf_binary+0x26c/0x11f4) > > > [ 14.694715] [] (load_elf_binary) from [] (search_binary_handler+0x98/0x244) > > > [ 14.703395] [] (search_binary_handler) from [] > > > (do_execveat_common+0x4dc/0x5bc) > > > [ 14.712421] [] (do_execveat_common) from [] (do_execve+0x28/0x30) > > > [ 14.720235] [] (do_execve) from [] (ret_fast_syscall+0x0/0x34) > > > [ 14.727782] ---[ end trace 5e3ca48b454c7e0a ]--- > > > [ 14.733758] ------------[ cut here ]------------ > > > > > > Has anyone else tested with CONFIG_ARM_LPAE=y that can confirm my findings? > > Uggh... I missed since i was looking at non LPAE omap2plus_defconfig. > > > > Dual A15 OMAP5432 with multi_v7_defconfig + CONFIG_ARM_LPAE=y > > https://github.com/nmenon/kernel-test-logs/blob/next-20150123/multi_lpae_defconfig/omap5-evm.txt > > > > Dual A15 DRA7/AM572x with same configuration as above. > > https://raw.githubusercontent.com/nmenon/kernel-test-logs/next-20150123/multi_lpae_defconfig/dra7xx-evm.txt > > https://github.com/nmenon/kernel-test-logs/blob/next-20150123/multi_lpae_defconfig/am57xx-evm.txt > > > > Single A15 DRA72 with same configuration as above: > > https://raw.githubusercontent.com/nmenon/kernel-test-logs/next-20150123/multi_lpae_defconfig/dra72x-evm.txt > > > > You are right. the issue re-appears with LPAE on :( > > Apologies on missing that. > > Guys, could you instrument mm_{inc,dec}_nr_pmds() with dump_stack() + > printk() of the counter and add printk() on mmap_exit() then run a simple > program which triggers the issue? The simplest program I think we are all running is "boot to shell" - I mean, have'nt spend more time digging at it as I am not in a familiar territory here. :( is there any instrumentation patch you want us to try?
diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h index bcc5e300413f..bfd662e49a25 100644 --- a/arch/arm/include/asm/pgtable-2level.h +++ b/arch/arm/include/asm/pgtable-2level.h @@ -10,6 +10,8 @@ #ifndef _ASM_PGTABLE_2LEVEL_H #define _ASM_PGTABLE_2LEVEL_H +#define __PAGETABLE_PMD_FOLDED + /* * Hardware-wise, we have a two level page table structure, where the first * level has 4096 entries, and the second level has 256 entries. Each entry