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
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.
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
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.
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
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
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
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:
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, _
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
-
Andrew Morton -
Ard Biesheuvel -
Max Krummenacher -
Naresh Kamboju -
Russell King (Oracle)