All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	lkft-triage@lists.linaro.org,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	max.krummenacher@toradex.com, Shawn Guo <shawnguo@kernel.org>,
	Stefano Stabellini <stefano.stabellini@xilinx.com>,
	Christoph Hellwig <hch@lst.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext
Date: Wed, 20 Apr 2022 09:31:29 +0200	[thread overview]
Message-ID: <CAMj1kXFKzi14UCoiDOMwS5jyNz61_UzxGXm+ke0EWEt4nn6E1g@mail.gmail.com> (raw)
In-Reply-To: <CA+G9fYuACgY2hcAgh_LwVb9AURjodMJbV6SsJb90wj-0aJKUOw@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org>
To: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 open list <linux-kernel@vger.kernel.org>,
	 Linux-Next Mailing List <linux-next@vger.kernel.org>,
	lkft-triage@lists.linaro.org,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	 Arnd Bergmann <arnd@arndb.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	max.krummenacher@toradex.com, Shawn Guo <shawnguo@kernel.org>,
	Stefano Stabellini <stefano.stabellini@xilinx.com>,
	 Christoph Hellwig <hch@lst.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext
Date: Wed, 20 Apr 2022 09:31:29 +0200	[thread overview]
Message-ID: <CAMj1kXFKzi14UCoiDOMwS5jyNz61_UzxGXm+ke0EWEt4nn6E1g@mail.gmail.com> (raw)
In-Reply-To: <CA+G9fYuACgY2hcAgh_LwVb9AURjodMJbV6SsJb90wj-0aJKUOw@mail.gmail.com>

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

  parent reply	other threads:[~2022-04-20  7:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-19 10:58 [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext Naresh Kamboju
2022-04-19 10:58 ` Naresh Kamboju
2022-04-19 18:57 ` Russell King (Oracle)
2022-04-19 18:57   ` Russell King (Oracle)
2022-04-20  8:55   ` Naresh Kamboju
2022-04-20  8:55     ` Naresh Kamboju
2022-04-20  9:44     ` Russell King (Oracle)
2022-04-20  9:44       ` Russell King (Oracle)
2022-04-20  7:31 ` Ard Biesheuvel [this message]
2022-04-20  7:31   ` Ard Biesheuvel
2022-04-20  7:50   ` Max Krummenacher
2022-04-20  7:50     ` Max Krummenacher
2022-04-20 13:04     ` Naresh Kamboju
2022-04-20 13:04       ` Naresh Kamboju
2022-04-20 21:53     ` Andrew Morton
2022-04-20 21:53       ` Andrew Morton
2022-04-20  8:54   ` Naresh Kamboju
2022-04-20  8:54     ` Naresh Kamboju

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMj1kXFKzi14UCoiDOMwS5jyNz61_UzxGXm+ke0EWEt4nn6E1g@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=ebiederm@xmission.com \
    --cc=hch@lst.de \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lkft-triage@lists.linaro.org \
    --cc=max.krummenacher@toradex.com \
    --cc=naresh.kamboju@linaro.org \
    --cc=sfr@canb.auug.org.au \
    --cc=shawnguo@kernel.org \
    --cc=stefano.stabellini@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.