* [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext @ 2022-04-19 10:58 Naresh Kamboju 2022-04-19 18:57 ` Russell King (Oracle) 2022-04-20 7:31 ` Ard Biesheuvel 0 siblings, 2 replies; 9+ messages in thread From: Naresh Kamboju @ 2022-04-19 10:58 UTC (permalink / raw) To: Linux ARM, open list, Linux-Next Mailing List, lkft-triage Cc: Stephen Rothwell, Russell King - ARM Linux, Arnd Bergmann, Ard Biesheuvel, Andrew Morton, max.krummenacher, Shawn Guo, Stefano Stabellini, Christoph Hellwig, Konrad Rzeszutek Wilk, Eric W. Biederman Linux next 20220419 boot failed on arm architecture qemu_arm and BeagleBoard x15 device. kernel crash log from x15: ----------------- [ 6.866516] 8<--- cut here --- [ 6.869598] Unable to handle kernel paging request at virtual address f000e62c [ 6.876861] [f000e62c] *pgd=82935811, *pte=00000000, *ppte=00000000 [ 6.883209] Internal error: Oops: 807 [#3] SMP ARM [ 6.888000] Modules linked in: [ 6.891082] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G D W 5.18.0-rc3-next-20220419 #1 [ 6.899993] Hardware name: Generic DRA74X (Flattened Device Tree) [ 6.906127] PC is at cpu_ca15_set_pte_ext+0x4c/0x58 [ 6.911041] LR is at handle_mm_fault+0x60c/0xed0 [ 6.915679] pc : [<c031f26c>] lr : [<c04cfeb8>] psr: 40000013 [ 6.921966] sp : f000dde8 ip : f000de44 fp : a0000013 [ 6.927215] r10: 00000000 r9 : 00000000 r8 : c1e95194 [ 6.932464] r7 : c3c95000 r6 : befffff1 r5 : 00000081 r4 : c29d8000 [ 6.939025] r3 : 00000000 r2 : 00000000 r1 : 00000040 r0 : f000de2c [ 6.945587] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 6.952758] Control: 10c5387d Table: 8020406a DAC: 00000051 [ 6.958526] Register r0 information: 2-page vmalloc region starting at 0xf000c000 allocated at kernel_clone+0x94/0x3b0 [ 6.969299] Register r1 information: non-paged memory [ 6.974365] Register r2 information: NULL pointer [ 6.979095] Register r3 information: NULL pointer [ 6.983825] Register r4 information: slab task_struct start c29d8000 pointer offset 0 [ 6.991729] Register r5 information: non-paged memory [ 6.996795] Register r6 information: non-paged memory [ 7.001861] Register r7 information: slab vm_area_struct start c3c95000 pointer offset 0 [ 7.010009] Register r8 information: non-slab/vmalloc memory [ 7.015716] Register r9 information: NULL pointer [ 7.020446] Register r10 information: NULL pointer [ 7.025238] Register r11 information: non-paged memory [ 7.030426] Register r12 information: 2-page vmalloc region starting at 0xf000c000 allocated at kernel_clone+0x94/0x3b0 [ 7.041259] Process swapper/0 (pid: 1, stack limit = 0xfaff0077) [ 7.047302] Stack: (0xf000dde8 to 0xf000e000) [ 7.051696] dde0: c29d8000 00000cc0 c20a1108 c2065fa0 c1e09f50 b6db6db7 [ 7.059906] de00: c195bf0c 17c0f572 c29d8000 c3c95000 00000cc0 000befff befff000 befffff1 [ 7.068115] de20: 00000081 c3c3afb8 c3c3afb8 00000000 00000000 00000000 00000000 00000000 [ 7.076324] de40: 00000000 17c0f572 befff000 c3c95000 00002017 befffff1 00002017 00002fb8 [ 7.084564] de60: c2d04000 00000081 c29d8000 c04c6790 c20d01d4 00000000 00000001 c20ce440 [ 7.092773] de80: c1e10bcc fffff000 00000000 c2a45680 eeb33cc0 c29d8000 00000000 c2d04000 [ 7.100982] dea0: befffff1 f000df18 00000000 00002017 c20661a0 c04c77e8 f000df18 00000000 [ 7.109222] dec0: 00000000 c1d95c40 00000002 c20661e0 00000000 00000001 00000000 c04c7ad0 [ 7.117431] dee0: 00000011 c2d02a00 00000001 befffff1 c29d8000 00000000 00000011 c2a30010 [ 7.125640] df00: c29d8000 c0524c24 f000df18 00000000 00000000 2cd9e000 c1d95c40 17c0f572 [ 7.133850] df20: 00000000 c2d02a00 0000000b 00000ffc 00000000 befffff1 00000000 c0524f74 [ 7.142089] df40: c1e0e394 c2d02a00 c209a71c 38e38e39 c29d8000 bee00008 c2d02a00 c2a30000 [ 7.150299] df60: c1e0e394 c1e0e420 00000000 00000000 00000000 c05266bc c209a000 c1944c60 [ 7.158508] df80: 00000000 00000000 00000000 c129d2b4 c209a000 c1e0e394 00000000 c12b5600 [ 7.166748] dfa0: 00000000 c12b5518 00000000 c0300168 00000000 00000000 00000000 00000000 [ 7.174957] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.183166] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 7.191406] Code: 13110001 12211b02 13110b02 03a03000 (e5a03800) [ 7.197570] ---[ end trace 0000000000000000 ]--- [ 7.202209] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> metadata: git_ref: master git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next git_sha: 634de1db0e9bbeb90d7b01020e59ec3dab4d38a1 git_describe: next-20220419 kernel-config: https://builds.tuxbuild.com/280TXP6P7tIBfnowvFY4wobXp3R/config System.map: https://builds.tuxbuild.com/280TXP6P7tIBfnowvFY4wobXp3R/System.map vmlinux.xz: https://builds.tuxbuild.com/280TXP6P7tIBfnowvFY4wobXp3R/vmlinux.xz build-url: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next/-/pipelines/519362851 build: https://builds.tuxbuild.com/280TXP6P7tIBfnowvFY4wobXp3R toolchain: gcc-10 -- Linaro LKFT https://lkft.linaro.org [1] https://lkft.validation.linaro.org/scheduler/job/4921995#L2616 [2] https://lkft.validation.linaro.org/scheduler/job/4922061#L552 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext 2022-04-19 10:58 [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext Naresh Kamboju @ 2022-04-19 18:57 ` Russell King (Oracle) 2022-04-20 8:55 ` Naresh Kamboju 2022-04-20 7:31 ` Ard Biesheuvel 1 sibling, 1 reply; 9+ messages in thread From: Russell King (Oracle) @ 2022-04-19 18:57 UTC (permalink / raw) To: Naresh Kamboju Cc: Linux ARM, open list, Linux-Next Mailing List, lkft-triage, Stephen Rothwell, Arnd Bergmann, Ard Biesheuvel, Andrew Morton, max.krummenacher, Shawn Guo, Stefano Stabellini, Christoph Hellwig, Konrad Rzeszutek Wilk, Eric W. Biederman On Tue, Apr 19, 2022 at 04:28:52PM +0530, Naresh Kamboju wrote: > Linux next 20220419 boot failed on arm architecture qemu_arm and BeagleBoard > x15 device. Was the immediately previous linux-next behaving correctly? If so, nothing has changed in the ARM32 kernel tree, so this must be someone else's issue - code that someone else has pushed into linux-next. It looks to me like someone is walking the page tables incorrectly, somewhere buried in handle_mm_fault(), because the PTE pointer is in the upper-2k of a 4k page, which is most definitely illegal on arm32. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext 2022-04-19 18:57 ` Russell King (Oracle) @ 2022-04-20 8:55 ` Naresh Kamboju 2022-04-20 9:44 ` Russell King (Oracle) 0 siblings, 1 reply; 9+ messages in thread From: Naresh Kamboju @ 2022-04-20 8:55 UTC (permalink / raw) To: Russell King (Oracle) Cc: Linux ARM, open list, Linux-Next Mailing List, lkft-triage, Stephen Rothwell, Arnd Bergmann, Ard Biesheuvel, Andrew Morton, max.krummenacher, Shawn Guo, Stefano Stabellini, Christoph Hellwig, Konrad Rzeszutek Wilk, Eric W. Biederman On Wed, 20 Apr 2022 at 00:28, Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > On Tue, Apr 19, 2022 at 04:28:52PM +0530, Naresh Kamboju wrote: > > Linux next 20220419 boot failed on arm architecture qemu_arm and BeagleBoard > > x15 device. > > Was the immediately previous linux-next behaving correctly? This crash started happening from the next-20220413 tag. - Naresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext 2022-04-20 8:55 ` Naresh Kamboju @ 2022-04-20 9:44 ` Russell King (Oracle) 0 siblings, 0 replies; 9+ messages in thread From: Russell King (Oracle) @ 2022-04-20 9:44 UTC (permalink / raw) To: Naresh Kamboju Cc: Linux ARM, open list, Linux-Next Mailing List, lkft-triage, Stephen Rothwell, Arnd Bergmann, Ard Biesheuvel, Andrew Morton, max.krummenacher, Shawn Guo, Stefano Stabellini, Christoph Hellwig, Konrad Rzeszutek Wilk, Eric W. Biederman On Wed, Apr 20, 2022 at 02:25:32PM +0530, Naresh Kamboju wrote: > On Wed, 20 Apr 2022 at 00:28, Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > > > On Tue, Apr 19, 2022 at 04:28:52PM +0530, Naresh Kamboju wrote: > > > Linux next 20220419 boot failed on arm architecture qemu_arm and BeagleBoard > > > x15 device. > > > > Was the immediately previous linux-next behaving correctly? > > This crash started happening from the next-20220413 tag. That rules out any arm32 specific changes - the last time my tree changed in for-next was 1st April. Ard points out that the pte table is on the stack, which it really should not be. I'm guessing there's some inappropriate generic kernel change that has broken arm32. A pte table should never ever appear on a kernel stack. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext 2022-04-19 10:58 [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext Naresh Kamboju 2022-04-19 18:57 ` Russell King (Oracle) @ 2022-04-20 7:31 ` Ard Biesheuvel 2022-04-20 7:50 ` Max Krummenacher 2022-04-20 8:54 ` Naresh Kamboju 1 sibling, 2 replies; 9+ messages in thread From: Ard Biesheuvel @ 2022-04-20 7:31 UTC (permalink / raw) To: Naresh Kamboju Cc: Linux ARM, open list, Linux-Next Mailing List, lkft-triage, Stephen Rothwell, Russell King - ARM Linux, Arnd Bergmann, Andrew Morton, max.krummenacher, Shawn Guo, Stefano Stabellini, Christoph Hellwig, Konrad Rzeszutek Wilk, Eric W. Biederman On Tue, 19 Apr 2022 at 12:59, Naresh Kamboju <naresh.kamboju@linaro.org> wrote: > > Linux next 20220419 boot failed on arm architecture qemu_arm and BeagleBoard > x15 device. > > kernel crash log from x15: > ----------------- > [ 6.866516] 8<--- cut here --- > [ 6.869598] Unable to handle kernel paging request at virtual > address f000e62c > [ 6.876861] [f000e62c] *pgd=82935811, *pte=00000000, *ppte=00000000 > [ 6.883209] Internal error: Oops: 807 [#3] SMP ARM > [ 6.888000] Modules linked in: > [ 6.891082] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G D W > 5.18.0-rc3-next-20220419 #1 > [ 6.899993] Hardware name: Generic DRA74X (Flattened Device Tree) > [ 6.906127] PC is at cpu_ca15_set_pte_ext+0x4c/0x58 > [ 6.911041] LR is at handle_mm_fault+0x60c/0xed0 > [ 6.915679] pc : [<c031f26c>] lr : [<c04cfeb8>] psr: 40000013 > [ 6.921966] sp : f000dde8 ip : f000de44 fp : a0000013 > [ 6.927215] r10: 00000000 r9 : 00000000 r8 : c1e95194 > [ 6.932464] r7 : c3c95000 r6 : befffff1 r5 : 00000081 r4 : c29d8000 > [ 6.939025] r3 : 00000000 r2 : 00000000 r1 : 00000040 r0 : f000de2c > [ 6.945587] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > [ 6.952758] Control: 10c5387d Table: 8020406a DAC: 00000051 > [ 6.958526] Register r0 information: 2-page vmalloc region starting > at 0xf000c000 allocated at kernel_clone+0x94/0x3b0 > [ 6.969299] Register r1 information: non-paged memory > [ 6.974365] Register r2 information: NULL pointer > [ 6.979095] Register r3 information: NULL pointer > [ 6.983825] Register r4 information: slab task_struct start > c29d8000 pointer offset 0 > [ 6.991729] Register r5 information: non-paged memory > [ 6.996795] Register r6 information: non-paged memory > [ 7.001861] Register r7 information: slab vm_area_struct start > c3c95000 pointer offset 0 > [ 7.010009] Register r8 information: non-slab/vmalloc memory > [ 7.015716] Register r9 information: NULL pointer > [ 7.020446] Register r10 information: NULL pointer > [ 7.025238] Register r11 information: non-paged memory > [ 7.030426] Register r12 information: 2-page vmalloc region > starting at 0xf000c000 allocated at kernel_clone+0x94/0x3b0 > [ 7.041259] Process swapper/0 (pid: 1, stack limit = 0xfaff0077) > [ 7.047302] Stack: (0xf000dde8 to 0xf000e000) > [ 7.051696] dde0: c29d8000 00000cc0 c20a1108 > c2065fa0 c1e09f50 b6db6db7 > [ 7.059906] de00: c195bf0c 17c0f572 c29d8000 c3c95000 00000cc0 > 000befff befff000 befffff1 > [ 7.068115] de20: 00000081 c3c3afb8 c3c3afb8 00000000 00000000 > 00000000 00000000 00000000 > [ 7.076324] de40: 00000000 17c0f572 befff000 c3c95000 00002017 > befffff1 00002017 00002fb8 > [ 7.084564] de60: c2d04000 00000081 c29d8000 c04c6790 c20d01d4 > 00000000 00000001 c20ce440 > [ 7.092773] de80: c1e10bcc fffff000 00000000 c2a45680 eeb33cc0 > c29d8000 00000000 c2d04000 > [ 7.100982] dea0: befffff1 f000df18 00000000 00002017 c20661a0 > c04c77e8 f000df18 00000000 > [ 7.109222] dec0: 00000000 c1d95c40 00000002 c20661e0 00000000 > 00000001 00000000 c04c7ad0 > [ 7.117431] dee0: 00000011 c2d02a00 00000001 befffff1 c29d8000 > 00000000 00000011 c2a30010 > [ 7.125640] df00: c29d8000 c0524c24 f000df18 00000000 00000000 > 2cd9e000 c1d95c40 17c0f572 > [ 7.133850] df20: 00000000 c2d02a00 0000000b 00000ffc 00000000 > befffff1 00000000 c0524f74 > [ 7.142089] df40: c1e0e394 c2d02a00 c209a71c 38e38e39 c29d8000 > bee00008 c2d02a00 c2a30000 > [ 7.150299] df60: c1e0e394 c1e0e420 00000000 00000000 00000000 > c05266bc c209a000 c1944c60 > [ 7.158508] df80: 00000000 00000000 00000000 c129d2b4 c209a000 > c1e0e394 00000000 c12b5600 > [ 7.166748] dfa0: 00000000 c12b5518 00000000 c0300168 00000000 > 00000000 00000000 00000000 > [ 7.174957] dfc0: 00000000 00000000 00000000 00000000 00000000 > 00000000 00000000 00000000 > [ 7.183166] dfe0: 00000000 00000000 00000000 00000000 00000013 > 00000000 00000000 00000000 > [ 7.191406] Code: 13110001 12211b02 13110b02 03a03000 (e5a03800) This decodes to 0: 13110001 tstne r1, #1 4: 12211b02 eorne r1, r1, #2048 ; 0x800 8: 13110b02 tstne r1, #2048 ; 0x800 c: 03a03000 moveq r3, #0 10:* e5a03800 str r3, [r0, #2048]! ; 0x800 <-- trapping instruction and R0 points into the stack. So we are updating a PTE that is located on the stack rather than in a page table somewhere, which seems very odd. However, this could be a latent bug that got uncovered by the VMAP stacks changes. Unfortunately, the vmlinux.xz file I downloaded from the link below seems to be different from the one that produced the crash, given that the LR address of c04cfeb8 does not seem to correspond with handle_mm_fault+0x60c/0xed0. Can you please double check the artifacts? > metadata: > git_ref: master > git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next > git_sha: 634de1db0e9bbeb90d7b01020e59ec3dab4d38a1 > git_describe: next-20220419 > kernel-config: https://builds.tuxbuild.com/280TXP6P7tIBfnowvFY4wobXp3R/config > System.map: https://builds.tuxbuild.com/280TXP6P7tIBfnowvFY4wobXp3R/System.map > vmlinux.xz: https://builds.tuxbuild.com/280TXP6P7tIBfnowvFY4wobXp3R/vmlinux.xz > build-url: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next/-/pipelines/519362851 > build: https://builds.tuxbuild.com/280TXP6P7tIBfnowvFY4wobXp3R > toolchain: gcc-10 > > -- > Linaro LKFT > https://lkft.linaro.org > > [1] https://lkft.validation.linaro.org/scheduler/job/4921995#L2616 > [2] https://lkft.validation.linaro.org/scheduler/job/4922061#L552 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext 2022-04-20 7:31 ` Ard Biesheuvel @ 2022-04-20 7:50 ` Max Krummenacher 2022-04-20 13:04 ` Naresh Kamboju 2022-04-20 21:53 ` Andrew Morton 2022-04-20 8:54 ` Naresh Kamboju 1 sibling, 2 replies; 9+ messages in thread From: Max Krummenacher @ 2022-04-20 7:50 UTC (permalink / raw) To: Ard Biesheuvel, Naresh Kamboju Cc: Linux ARM, open list, Linux-Next Mailing List, lkft-triage, Stephen Rothwell, Russell King - ARM Linux, Arnd Bergmann, Andrew Morton, max.krummenacher, Shawn Guo, Stefano Stabellini, Christoph Hellwig, Konrad Rzeszutek Wilk, Eric W. Biederman, Russell King (Oracle) Am Mittwoch, den 20.04.2022, 09:31 +0200 schrieb Ard Biesheuvel: > On Tue, 19 Apr 2022 at 12:59, Naresh Kamboju <naresh.kamboju@linaro.org> wrote: > > Linux next 20220419 boot failed on arm architecture qemu_arm and BeagleBoard > > x15 device. > > > > kernel crash log from x15: > > ----------------- > > [ 6.866516] 8<--- cut here --- > > [ 6.869598] Unable to handle kernel paging request at virtual > > address f000e62c > > [ 6.876861] [f000e62c] *pgd=82935811, *pte=00000000, *ppte=00000000 > > [ 6.883209] Internal error: Oops: 807 [#3] SMP ARM > > [ 6.888000] Modules linked in: > > [ 6.891082] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G D W > > 5.18.0-rc3-next-20220419 #1 > > [ 6.899993] Hardware name: Generic DRA74X (Flattened Device Tree) > > [ 6.906127] PC is at cpu_ca15_set_pte_ext+0x4c/0x58 > > [ 6.911041] LR is at handle_mm_fault+0x60c/0xed0 > > [ 6.915679] pc : [<c031f26c>] lr : [<c04cfeb8>] psr: 40000013 > > [ 6.921966] sp : f000dde8 ip : f000de44 fp : a0000013 > > [ 6.927215] r10: 00000000 r9 : 00000000 r8 : c1e95194 > > [ 6.932464] r7 : c3c95000 r6 : befffff1 r5 : 00000081 r4 : c29d8000 > > [ 6.939025] r3 : 00000000 r2 : 00000000 r1 : 00000040 r0 : f000de2c > > [ 6.945587] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > > [ 6.952758] Control: 10c5387d Table: 8020406a DAC: 00000051 > > [ 6.958526] Register r0 information: 2-page vmalloc region starting > > at 0xf000c000 allocated at kernel_clone+0x94/0x3b0 > > [ 6.969299] Register r1 information: non-paged memory > > [ 6.974365] Register r2 information: NULL pointer > > [ 6.979095] Register r3 information: NULL pointer > > [ 6.983825] Register r4 information: slab task_struct start > > c29d8000 pointer offset 0 > > [ 6.991729] Register r5 information: non-paged memory > > [ 6.996795] Register r6 information: non-paged memory > > [ 7.001861] Register r7 information: slab vm_area_struct start > > c3c95000 pointer offset 0 > > [ 7.010009] Register r8 information: non-slab/vmalloc memory > > [ 7.015716] Register r9 information: NULL pointer > > [ 7.020446] Register r10 information: NULL pointer > > [ 7.025238] Register r11 information: non-paged memory > > [ 7.030426] Register r12 information: 2-page vmalloc region > > starting at 0xf000c000 allocated at kernel_clone+0x94/0x3b0 > > [ 7.041259] Process swapper/0 (pid: 1, stack limit = 0xfaff0077) > > [ 7.047302] Stack: (0xf000dde8 to 0xf000e000) > > [ 7.051696] dde0: c29d8000 00000cc0 c20a1108 > > c2065fa0 c1e09f50 b6db6db7 > > [ 7.059906] de00: c195bf0c 17c0f572 c29d8000 c3c95000 00000cc0 > > 000befff befff000 befffff1 > > [ 7.068115] de20: 00000081 c3c3afb8 c3c3afb8 00000000 00000000 > > 00000000 00000000 00000000 > > [ 7.076324] de40: 00000000 17c0f572 befff000 c3c95000 00002017 > > befffff1 00002017 00002fb8 > > [ 7.084564] de60: c2d04000 00000081 c29d8000 c04c6790 c20d01d4 > > 00000000 00000001 c20ce440 > > [ 7.092773] de80: c1e10bcc fffff000 00000000 c2a45680 eeb33cc0 > > c29d8000 00000000 c2d04000 > > [ 7.100982] dea0: befffff1 f000df18 00000000 00002017 c20661a0 > > c04c77e8 f000df18 00000000 > > [ 7.109222] dec0: 00000000 c1d95c40 00000002 c20661e0 00000000 > > 00000001 00000000 c04c7ad0 > > [ 7.117431] dee0: 00000011 c2d02a00 00000001 befffff1 c29d8000 > > 00000000 00000011 c2a30010 > > [ 7.125640] df00: c29d8000 c0524c24 f000df18 00000000 00000000 > > 2cd9e000 c1d95c40 17c0f572 > > [ 7.133850] df20: 00000000 c2d02a00 0000000b 00000ffc 00000000 > > befffff1 00000000 c0524f74 > > [ 7.142089] df40: c1e0e394 c2d02a00 c209a71c 38e38e39 c29d8000 > > bee00008 c2d02a00 c2a30000 > > [ 7.150299] df60: c1e0e394 c1e0e420 00000000 00000000 00000000 > > c05266bc c209a000 c1944c60 > > [ 7.158508] df80: 00000000 00000000 00000000 c129d2b4 c209a000 > > c1e0e394 00000000 c12b5600 > > [ 7.166748] dfa0: 00000000 c12b5518 00000000 c0300168 00000000 > > 00000000 00000000 00000000 > > [ 7.174957] dfc0: 00000000 00000000 00000000 00000000 00000000 > > 00000000 00000000 00000000 > > [ 7.183166] dfe0: 00000000 00000000 00000000 00000000 00000013 > > 00000000 00000000 00000000 > > [ 7.191406] Code: 13110001 12211b02 13110b02 03a03000 (e5a03800) > > This decodes to > > 0: 13110001 tstne r1, #1 > 4: 12211b02 eorne r1, r1, #2048 ; 0x800 > 8: 13110b02 tstne r1, #2048 ; 0x800 > c: 03a03000 moveq r3, #0 > 10:* e5a03800 str r3, [r0, #2048]! ; 0x800 <-- trapping instruction > > and R0 points into the stack. So we are updating a PTE that is located > on the stack rather than in a page table somewhere, which seems very > odd. However, this could be a latent bug that got uncovered by the > VMAP stacks changes. > > Unfortunately, the vmlinux.xz file I downloaded from the link below > seems to be different from the one that produced the crash, given that > the LR address of c04cfeb8 does not seem to correspond with > handle_mm_fault+0x60c/0xed0. > > Can you please double check the artifacts? Commit "mm: check against orig_pte for finish_fault()" introduced this, i.e. on yesterdays next reverting a066bab3c0eb made a i.MX6 boot again. A fix is discussed here: https://lore.kernel.org/all/YliNP7ADcdc4Puvs@xz-m1.local/ Max > > > > > metadata: > > git_ref: master > > git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next > > git_sha: 634de1db0e9bbeb90d7b01020e59ec3dab4d38a1 > > git_describe: next-20220419 > > kernel-config: https://builds.tuxbuild.com/280TXP6P7tIBfnowvFY4wobXp3R/config > > System.map: https://builds.tuxbuild.com/280TXP6P7tIBfnowvFY4wobXp3R/System.map > > vmlinux.xz: https://builds.tuxbuild.com/280TXP6P7tIBfnowvFY4wobXp3R/vmlinux.xz > > build-url: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next/-/pipelines/519362851 > > build: https://builds.tuxbuild.com/280TXP6P7tIBfnowvFY4wobXp3R > > toolchain: gcc-10 > > > > -- > > Linaro LKFT > > https://lkft.linaro.org > > > > [1] https://lkft.validation.linaro.org/scheduler/job/4921995#L2616 > > [2] https://lkft.validation.linaro.org/scheduler/job/4922061#L552 > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext 2022-04-20 7:50 ` Max Krummenacher @ 2022-04-20 13:04 ` Naresh Kamboju 2022-04-20 21:53 ` Andrew Morton 1 sibling, 0 replies; 9+ messages in thread From: Naresh Kamboju @ 2022-04-20 13:04 UTC (permalink / raw) To: Max Krummenacher Cc: Ard Biesheuvel, Russell King - ARM Linux, Linux ARM, open list, Linux-Next Mailing List, lkft-triage, Stephen Rothwell, Arnd Bergmann, Andrew Morton, max.krummenacher, Shawn Guo, Stefano Stabellini, Christoph Hellwig, Konrad Rzeszutek Wilk, Eric W. Biederman Hi Max, On Wed, 20 Apr 2022 at 13:20, Max Krummenacher <max.oss.09@gmail.com> wrote: > > Am Mittwoch, den 20.04.2022, 09:31 +0200 schrieb Ard Biesheuvel: > > On Tue, 19 Apr 2022 at 12:59, Naresh Kamboju <naresh.kamboju@linaro.org> wrote: > > > Linux next 20220419 boot failed on arm architecture qemu_arm and BeagleBoard > > > x15 device. > > > > > > kernel crash log from x15: > > > ----------------- > > > [ 6.866516] 8<--- cut here --- > > > [ 6.869598] Unable to handle kernel paging request at virtual > > > address f000e62c <trim> > > Unfortunately, the vmlinux.xz file I downloaded from the link below > > seems to be different from the one that produced the crash, given that > > the LR address of c04cfeb8 does not seem to correspond with > > handle_mm_fault+0x60c/0xed0. > > > > Can you please double check the artifacts? > > Commit "mm: check against orig_pte for finish_fault()" introduced this, > i.e. on yesterdays next reverting a066bab3c0eb made a i.MX6 boot again. Thanks for the pointers, I have reverted the suggested commit and boot pass now. Revert "mm: check against orig_pte for finish_fault()" This reverts commit a066bab3c0eb8f6155257f1345f07d1f6550bc4a. > A fix is discussed here: > https://lore.kernel.org/all/YliNP7ADcdc4Puvs@xz-m1.local/ > > Max - Naresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext 2022-04-20 7:50 ` Max Krummenacher 2022-04-20 13:04 ` Naresh Kamboju @ 2022-04-20 21:53 ` Andrew Morton 1 sibling, 0 replies; 9+ messages in thread From: Andrew Morton @ 2022-04-20 21:53 UTC (permalink / raw) To: Max Krummenacher Cc: Ard Biesheuvel, Naresh Kamboju, Linux ARM, open list, Linux-Next Mailing List, lkft-triage, Stephen Rothwell, Russell King - ARM Linux, Arnd Bergmann, max.krummenacher, Shawn Guo, Stefano Stabellini, Christoph Hellwig, Konrad Rzeszutek Wilk, Eric W. Biederman On Wed, 20 Apr 2022 09:50:52 +0200 Max Krummenacher <max.oss.09@gmail.com> wrote: > > > > Unfortunately, the vmlinux.xz file I downloaded from the link below > > seems to be different from the one that produced the crash, given that > > the LR address of c04cfeb8 does not seem to correspond with > > handle_mm_fault+0x60c/0xed0. > > > > Can you please double check the artifacts? > > Commit "mm: check against orig_pte for finish_fault()" introduced this, > i.e. on yesterdays next reverting a066bab3c0eb made a i.MX6 boot again. > A fix is discussed here: > > https://lore.kernel.org/all/YliNP7ADcdc4Puvs@xz-m1.local/ > Thanks for finding that. I have Peter's fix queued and shall push out a snapshot later today, for integration into linux-next. From: Peter Xu <peterx@redhat.com> Subject: mm-check-against-orig_pte-for-finish_fault-fix fix crash reported by Marek Link: https://lkml.kernel.org/r/Ylb9rXJyPm8/ao8f@xz-m1.local Signed-off-by: Peter Xu <peterx@redhat.com> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: David Hildenbrand <david@redhat.com> Cc: Hugh Dickins <hughd@google.com> Cc: Jerome Glisse <jglisse@redhat.com> Cc: "Kirill A . Shutemov" <kirill@shutemov.name> Cc: Matthew Wilcox <willy@infradead.org> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Nadav Amit <nadav.amit@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- --- a/include/linux/mm_types.h~mm-check-against-orig_pte-for-finish_fault-fix +++ a/include/linux/mm_types.h @@ -814,6 +814,8 @@ typedef struct { * @FAULT_FLAG_UNSHARE: The fault is an unsharing request to unshare (and mark * exclusive) a possibly shared anonymous page that is * mapped R/O. + * @FAULT_FLAG_ORIG_PTE_VALID: whether the fault has vmf->orig_pte cached. + * We should only access orig_pte if this flag set. * * About @FAULT_FLAG_ALLOW_RETRY and @FAULT_FLAG_TRIED: we can specify * whether we would allow page faults to retry by specifying these two @@ -850,6 +852,7 @@ enum fault_flag { FAULT_FLAG_INSTRUCTION = 1 << 8, FAULT_FLAG_INTERRUPTIBLE = 1 << 9, FAULT_FLAG_UNSHARE = 1 << 10, + FAULT_FLAG_ORIG_PTE_VALID = 1 << 11, }; #endif /* _LINUX_MM_TYPES_H */ --- a/mm/memory.c~mm-check-against-orig_pte-for-finish_fault-fix +++ a/mm/memory.c @@ -4194,6 +4194,15 @@ void do_set_pte(struct vm_fault *vmf, st set_pte_at(vma->vm_mm, addr, vmf->pte, entry); } +static bool vmf_pte_changed(struct vm_fault *vmf) +{ + if (vmf->flags & FAULT_FLAG_ORIG_PTE_VALID) { + return !pte_same(*vmf->pte, vmf->orig_pte); + } + + return !pte_none(*vmf->pte); +} + /** * finish_fault - finish page fault once we have prepared the page to fault * @@ -4252,7 +4261,7 @@ vm_fault_t finish_fault(struct vm_fault vmf->address, &vmf->ptl); ret = 0; /* Re-check under ptl */ - if (likely(pte_same(*vmf->pte, vmf->orig_pte))) + if (likely(!vmf_pte_changed(vmf))) do_set_pte(vmf, page, vmf->address); else ret = VM_FAULT_NOPAGE; @@ -4720,13 +4729,7 @@ static vm_fault_t handle_pte_fault(struc * concurrent faults and from rmap lookups. */ vmf->pte = NULL; - /* - * Always initialize orig_pte. This matches with below - * code to have orig_pte to be the none pte if pte==NULL. - * This makes the rest code to be always safe to reference - * it, e.g. in finish_fault() we'll detect pte changes. - */ - pte_clear(vmf->vma->vm_mm, vmf->address, &vmf->orig_pte); + vmf->flags &= ~FAULT_FLAG_ORIG_PTE_VALID; } else { /* * If a huge pmd materialized under us just retry later. Use @@ -4750,6 +4753,7 @@ static vm_fault_t handle_pte_fault(struc */ vmf->pte = pte_offset_map(vmf->pmd, vmf->address); vmf->orig_pte = *vmf->pte; + vmf->flags |= FAULT_FLAG_ORIG_PTE_VALID; /* * some architectures can have larger ptes than wordsize, _ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext 2022-04-20 7:31 ` Ard Biesheuvel 2022-04-20 7:50 ` Max Krummenacher @ 2022-04-20 8:54 ` Naresh Kamboju 1 sibling, 0 replies; 9+ messages in thread From: Naresh Kamboju @ 2022-04-20 8:54 UTC (permalink / raw) To: Ard Biesheuvel Cc: Linux ARM, open list, Linux-Next Mailing List, lkft-triage, Stephen Rothwell, Russell King - ARM Linux, Arnd Bergmann, Andrew Morton, max.krummenacher, Shawn Guo, Stefano Stabellini, Christoph Hellwig, Konrad Rzeszutek Wilk, Eric W. Biederman On Wed, 20 Apr 2022 at 13:01, Ard Biesheuvel <ardb@kernel.org> wrote: > > On Tue, 19 Apr 2022 at 12:59, Naresh Kamboju <naresh.kamboju@linaro.org> wrote: > > > > Linux next 20220419 boot failed on arm architecture qemu_arm and BeagleBoard > > x15 device. > > > > kernel crash log from x15: > > ----------------- > > [ 6.866516] 8<--- cut here --- > > [ 6.869598] Unable to handle kernel paging request at virtual > > address f000e62c > > [ 6.876861] [f000e62c] *pgd=82935811, *pte=00000000, *ppte=00000000 > > [ 6.883209] Internal error: Oops: 807 [#3] SMP ARM > > [ 6.888000] Modules linked in: > > [ 6.891082] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G D W > > 5.18.0-rc3-next-20220419 #1 > > [ 6.899993] Hardware name: Generic DRA74X (Flattened Device Tree) > > [ 6.906127] PC is at cpu_ca15_set_pte_ext+0x4c/0x58 > > [ 6.911041] LR is at handle_mm_fault+0x60c/0xed0 > > [ 6.915679] pc : [<c031f26c>] lr : [<c04cfeb8>] psr: 40000013 > > [ 6.921966] sp : f000dde8 ip : f000de44 fp : a0000013 > > [ 6.927215] r10: 00000000 r9 : 00000000 r8 : c1e95194 > > [ 6.932464] r7 : c3c95000 r6 : befffff1 r5 : 00000081 r4 : c29d8000 > > [ 6.939025] r3 : 00000000 r2 : 00000000 r1 : 00000040 r0 : f000de2c > > [ 6.945587] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > > [ 6.952758] Control: 10c5387d Table: 8020406a DAC: 00000051 > > [ 6.958526] Register r0 information: 2-page vmalloc region starting > > at 0xf000c000 allocated at kernel_clone+0x94/0x3b0 > > [ 6.969299] Register r1 information: non-paged memory > > [ 6.974365] Register r2 information: NULL pointer > > [ 6.979095] Register r3 information: NULL pointer > > [ 6.983825] Register r4 information: slab task_struct start > > c29d8000 pointer offset 0 > > [ 6.991729] Register r5 information: non-paged memory > > [ 6.996795] Register r6 information: non-paged memory > > [ 7.001861] Register r7 information: slab vm_area_struct start > > c3c95000 pointer offset 0 > > [ 7.010009] Register r8 information: non-slab/vmalloc memory > > [ 7.015716] Register r9 information: NULL pointer > > [ 7.020446] Register r10 information: NULL pointer > > [ 7.025238] Register r11 information: non-paged memory > > [ 7.030426] Register r12 information: 2-page vmalloc region > > starting at 0xf000c000 allocated at kernel_clone+0x94/0x3b0 > > [ 7.041259] Process swapper/0 (pid: 1, stack limit = 0xfaff0077) > > [ 7.047302] Stack: (0xf000dde8 to 0xf000e000) > > [ 7.051696] dde0: c29d8000 00000cc0 c20a1108 > > c2065fa0 c1e09f50 b6db6db7 > > [ 7.059906] de00: c195bf0c 17c0f572 c29d8000 c3c95000 00000cc0 > > 000befff befff000 befffff1 > > [ 7.068115] de20: 00000081 c3c3afb8 c3c3afb8 00000000 00000000 > > 00000000 00000000 00000000 > > [ 7.076324] de40: 00000000 17c0f572 befff000 c3c95000 00002017 > > befffff1 00002017 00002fb8 > > [ 7.084564] de60: c2d04000 00000081 c29d8000 c04c6790 c20d01d4 > > 00000000 00000001 c20ce440 > > [ 7.092773] de80: c1e10bcc fffff000 00000000 c2a45680 eeb33cc0 > > c29d8000 00000000 c2d04000 > > [ 7.100982] dea0: befffff1 f000df18 00000000 00002017 c20661a0 > > c04c77e8 f000df18 00000000 > > [ 7.109222] dec0: 00000000 c1d95c40 00000002 c20661e0 00000000 > > 00000001 00000000 c04c7ad0 > > [ 7.117431] dee0: 00000011 c2d02a00 00000001 befffff1 c29d8000 > > 00000000 00000011 c2a30010 > > [ 7.125640] df00: c29d8000 c0524c24 f000df18 00000000 00000000 > > 2cd9e000 c1d95c40 17c0f572 > > [ 7.133850] df20: 00000000 c2d02a00 0000000b 00000ffc 00000000 > > befffff1 00000000 c0524f74 > > [ 7.142089] df40: c1e0e394 c2d02a00 c209a71c 38e38e39 c29d8000 > > bee00008 c2d02a00 c2a30000 > > [ 7.150299] df60: c1e0e394 c1e0e420 00000000 00000000 00000000 > > c05266bc c209a000 c1944c60 > > [ 7.158508] df80: 00000000 00000000 00000000 c129d2b4 c209a000 > > c1e0e394 00000000 c12b5600 > > [ 7.166748] dfa0: 00000000 c12b5518 00000000 c0300168 00000000 > > 00000000 00000000 00000000 > > [ 7.174957] dfc0: 00000000 00000000 00000000 00000000 00000000 > > 00000000 00000000 00000000 > > [ 7.183166] dfe0: 00000000 00000000 00000000 00000000 00000013 > > 00000000 00000000 00000000 > > [ 7.191406] Code: 13110001 12211b02 13110b02 03a03000 (e5a03800) > > This decodes to > > 0: 13110001 tstne r1, #1 > 4: 12211b02 eorne r1, r1, #2048 ; 0x800 > 8: 13110b02 tstne r1, #2048 ; 0x800 > c: 03a03000 moveq r3, #0 > 10:* e5a03800 str r3, [r0, #2048]! ; 0x800 <-- trapping instruction > > and R0 points into the stack. So we are updating a PTE that is located > on the stack rather than in a page table somewhere, which seems very > odd. However, this could be a latent bug that got uncovered by the > VMAP stacks changes. > > Unfortunately, the vmlinux.xz file I downloaded from the link below > seems to be different from the one that produced the crash, given that > the LR address of c04cfeb8 does not seem to correspond with > handle_mm_fault+0x60c/0xed0. > Can you please double check the artifacts? You can find the vmlinux.xz for the trace log I have pasted. vmlinux.xz : https://builds.tuxbuild.com/280TS8MuM6sYWk5aUtrvWIw0RQ7/vmlinux.xz artifact-location: https://builds.tuxbuild.com/280TS8MuM6sYWk5aUtrvWIw0RQ7 - Naresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-04-20 21:54 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-04-19 10:58 [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext Naresh Kamboju 2022-04-19 18:57 ` Russell King (Oracle) 2022-04-20 8:55 ` Naresh Kamboju 2022-04-20 9:44 ` Russell King (Oracle) 2022-04-20 7:31 ` Ard Biesheuvel 2022-04-20 7:50 ` Max Krummenacher 2022-04-20 13:04 ` Naresh Kamboju 2022-04-20 21:53 ` Andrew Morton 2022-04-20 8:54 ` Naresh Kamboju
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).