Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
On Thu, May 26, 2022 at 3:37 AM Heiko Stübner wrote: > > Am Mittwoch, 25. Mai 2022, 18:08:22 CEST schrieb Guo Ren: > > Thx Heiko & Guenter, > > > > On Wed, May 25, 2022 at 7:10 PM Heiko Stübner wrote: > > > > > > Am Mittwoch, 25. Mai 2022, 12:57:30 CEST schrieb Heiko Stübner: > > > > Am Mittwoch, 25. Mai 2022, 00:06:46 CEST schrieb Guenter Roeck: > > > > > On Wed, May 25, 2022 at 01:46:38AM +0800, Guo Ren wrote: > > > > > [ ... ] > > > > > > > > > > > > The problem is come from "__dls3's vdso decode part in musl's > > > > > > > ldso/dynlink.c". The ehdr->e_phnum & ehdr->e_phentsize are wrong. > > > > > > > > > > > > > > I think the root cause is from musl's implementation with the > > > > > > > wrong > > > > > > > elf parser. I would fix that soon. > > > > > > Not elf parser, it's "aux vector just past environ[]". I think I > > > > > > could > > > > > > solve this, but anyone who could help dig in is welcome. > > > > > > > > > > > > > > > > I am not sure I understand what you are saying here. Point is that my > > > > > root file system, generated with musl a year or so ago, crashes with > > > > > your patch set applied. That is a regression, even if there is a bug > > > > > in musl. > > Thx for the report, it's a valuable regression for riscv-compat. > > > > > > > > > > Also as I said in the other part of the thread, the rootfs seems > > > > innocent, > > > > as my completely-standard Debian riscv64 rootfs is also affected. > > > > > > > > The merged version seems to be v12 [0] - not sure how we this discussion > > > > ended up in v9, but I just tested this revision in two variants: > > > > > > > > - v5.17 + this v9 -> works nicely > > > > > > I take that back ... now going back to that build I somehow also run into > > > that issue here ... will investigate more. > > Yeah, it's my fault. I've fixed up it, please have a try: > > > > https://lore.kernel.org/linux-riscv/20220525160404.2930984-1-guo...@kernel.org/T/#u > > very cool that you found the issue. > I've tested your patch and it seems to fix the issue for me. > > Thanks for figuring out the cause I should thx Guenter Roeck, It just surprised me that compat_vdso could work with quite a lot of rv64 apps. > Heiko > > > > > > - v5.18-rc6 + this v9 (rebased onto it) -> breaks the boot > > > > The only rebase-conflict was with the introduction of restartable > > > > sequences and removal of the tracehook include, but turning > > > > CONFIG_RSEQ > > > > off doesn't seem to affect the breakage. > > > > > > > > So it looks like something changed between 5.17 and 5.18 that causes > > > > the issue. > > > > > > > > > > > > Heiko > > > > > > > > > > > > [0] > > > > https://lore.kernel.org/all/20220405071314.3225832-1-guo...@kernel.org/ > > > > > > > > > > > > > > > > > > > > > > > > > > -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
Am Mittwoch, 25. Mai 2022, 18:08:22 CEST schrieb Guo Ren: > Thx Heiko & Guenter, > > On Wed, May 25, 2022 at 7:10 PM Heiko Stübner wrote: > > > > Am Mittwoch, 25. Mai 2022, 12:57:30 CEST schrieb Heiko Stübner: > > > Am Mittwoch, 25. Mai 2022, 00:06:46 CEST schrieb Guenter Roeck: > > > > On Wed, May 25, 2022 at 01:46:38AM +0800, Guo Ren wrote: > > > > [ ... ] > > > > > > > > > > The problem is come from "__dls3's vdso decode part in musl's > > > > > > ldso/dynlink.c". The ehdr->e_phnum & ehdr->e_phentsize are wrong. > > > > > > > > > > > > I think the root cause is from musl's implementation with the wrong > > > > > > elf parser. I would fix that soon. > > > > > Not elf parser, it's "aux vector just past environ[]". I think I could > > > > > solve this, but anyone who could help dig in is welcome. > > > > > > > > > > > > > I am not sure I understand what you are saying here. Point is that my > > > > root file system, generated with musl a year or so ago, crashes with > > > > your patch set applied. That is a regression, even if there is a bug > > > > in musl. > Thx for the report, it's a valuable regression for riscv-compat. > > > > > > > Also as I said in the other part of the thread, the rootfs seems innocent, > > > as my completely-standard Debian riscv64 rootfs is also affected. > > > > > > The merged version seems to be v12 [0] - not sure how we this discussion > > > ended up in v9, but I just tested this revision in two variants: > > > > > > - v5.17 + this v9 -> works nicely > > > > I take that back ... now going back to that build I somehow also run into > > that issue here ... will investigate more. > Yeah, it's my fault. I've fixed up it, please have a try: > > https://lore.kernel.org/linux-riscv/20220525160404.2930984-1-guo...@kernel.org/T/#u very cool that you found the issue. I've tested your patch and it seems to fix the issue for me. Thanks for figuring out the cause Heiko > > > - v5.18-rc6 + this v9 (rebased onto it) -> breaks the boot > > > The only rebase-conflict was with the introduction of restartable > > > sequences and removal of the tracehook include, but turning CONFIG_RSEQ > > > off doesn't seem to affect the breakage. > > > > > > So it looks like something changed between 5.17 and 5.18 that causes the > > > issue. > > > > > > > > > Heiko > > > > > > > > > [0] > > > https://lore.kernel.org/all/20220405071314.3225832-1-guo...@kernel.org/ > > > > > > > > > > > > > >
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
Thx Heiko & Guenter, On Wed, May 25, 2022 at 7:10 PM Heiko Stübner wrote: > > Am Mittwoch, 25. Mai 2022, 12:57:30 CEST schrieb Heiko Stübner: > > Am Mittwoch, 25. Mai 2022, 00:06:46 CEST schrieb Guenter Roeck: > > > On Wed, May 25, 2022 at 01:46:38AM +0800, Guo Ren wrote: > > > [ ... ] > > > > > > > > The problem is come from "__dls3's vdso decode part in musl's > > > > > ldso/dynlink.c". The ehdr->e_phnum & ehdr->e_phentsize are wrong. > > > > > > > > > > I think the root cause is from musl's implementation with the wrong > > > > > elf parser. I would fix that soon. > > > > Not elf parser, it's "aux vector just past environ[]". I think I could > > > > solve this, but anyone who could help dig in is welcome. > > > > > > > > > > I am not sure I understand what you are saying here. Point is that my > > > root file system, generated with musl a year or so ago, crashes with > > > your patch set applied. That is a regression, even if there is a bug > > > in musl. Thx for the report, it's a valuable regression for riscv-compat. > > > > Also as I said in the other part of the thread, the rootfs seems innocent, > > as my completely-standard Debian riscv64 rootfs is also affected. > > > > The merged version seems to be v12 [0] - not sure how we this discussion > > ended up in v9, but I just tested this revision in two variants: > > > > - v5.17 + this v9 -> works nicely > > I take that back ... now going back to that build I somehow also run into > that issue here ... will investigate more. Yeah, it's my fault. I've fixed up it, please have a try: https://lore.kernel.org/linux-riscv/20220525160404.2930984-1-guo...@kernel.org/T/#u > > > > - v5.18-rc6 + this v9 (rebased onto it) -> breaks the boot > > The only rebase-conflict was with the introduction of restartable > > sequences and removal of the tracehook include, but turning CONFIG_RSEQ > > off doesn't seem to affect the breakage. > > > > So it looks like something changed between 5.17 and 5.18 that causes the > > issue. > > > > > > Heiko > > > > > > [0] https://lore.kernel.org/all/20220405071314.3225832-1-guo...@kernel.org/ > > > > > > -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
Am Mittwoch, 25. Mai 2022, 12:57:30 CEST schrieb Heiko Stübner: > Am Mittwoch, 25. Mai 2022, 00:06:46 CEST schrieb Guenter Roeck: > > On Wed, May 25, 2022 at 01:46:38AM +0800, Guo Ren wrote: > > [ ... ] > > > > > > The problem is come from "__dls3's vdso decode part in musl's > > > > ldso/dynlink.c". The ehdr->e_phnum & ehdr->e_phentsize are wrong. > > > > > > > > I think the root cause is from musl's implementation with the wrong > > > > elf parser. I would fix that soon. > > > Not elf parser, it's "aux vector just past environ[]". I think I could > > > solve this, but anyone who could help dig in is welcome. > > > > > > > I am not sure I understand what you are saying here. Point is that my > > root file system, generated with musl a year or so ago, crashes with > > your patch set applied. That is a regression, even if there is a bug > > in musl. > > Also as I said in the other part of the thread, the rootfs seems innocent, > as my completely-standard Debian riscv64 rootfs is also affected. > > The merged version seems to be v12 [0] - not sure how we this discussion > ended up in v9, but I just tested this revision in two variants: > > - v5.17 + this v9 -> works nicely I take that back ... now going back to that build I somehow also run into that issue here ... will investigate more. > - v5.18-rc6 + this v9 (rebased onto it) -> breaks the boot > The only rebase-conflict was with the introduction of restartable > sequences and removal of the tracehook include, but turning CONFIG_RSEQ > off doesn't seem to affect the breakage. > > So it looks like something changed between 5.17 and 5.18 that causes the > issue. > > > Heiko > > > [0] https://lore.kernel.org/all/20220405071314.3225832-1-guo...@kernel.org/ >
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
Am Mittwoch, 25. Mai 2022, 00:06:46 CEST schrieb Guenter Roeck: > On Wed, May 25, 2022 at 01:46:38AM +0800, Guo Ren wrote: > [ ... ] > > > > The problem is come from "__dls3's vdso decode part in musl's > > > ldso/dynlink.c". The ehdr->e_phnum & ehdr->e_phentsize are wrong. > > > > > > I think the root cause is from musl's implementation with the wrong > > > elf parser. I would fix that soon. > > Not elf parser, it's "aux vector just past environ[]". I think I could > > solve this, but anyone who could help dig in is welcome. > > > > I am not sure I understand what you are saying here. Point is that my > root file system, generated with musl a year or so ago, crashes with > your patch set applied. That is a regression, even if there is a bug > in musl. Also as I said in the other part of the thread, the rootfs seems innocent, as my completely-standard Debian riscv64 rootfs is also affected. The merged version seems to be v12 [0] - not sure how we this discussion ended up in v9, but I just tested this revision in two variants: - v5.17 + this v9 -> works nicely - v5.18-rc6 + this v9 (rebased onto it) -> breaks the boot The only rebase-conflict was with the introduction of restartable sequences and removal of the tracehook include, but turning CONFIG_RSEQ off doesn't seem to affect the breakage. So it looks like something changed between 5.17 and 5.18 that causes the issue. Heiko [0] https://lore.kernel.org/all/20220405071314.3225832-1-guo...@kernel.org/
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
On Wed, May 25, 2022 at 01:46:38AM +0800, Guo Ren wrote: [ ... ] > > The problem is come from "__dls3's vdso decode part in musl's > > ldso/dynlink.c". The ehdr->e_phnum & ehdr->e_phentsize are wrong. > > > > I think the root cause is from musl's implementation with the wrong > > elf parser. I would fix that soon. > Not elf parser, it's "aux vector just past environ[]". I think I could > solve this, but anyone who could help dig in is welcome. > I am not sure I understand what you are saying here. Point is that my root file system, generated with musl a year or so ago, crashes with your patch set applied. That is a regression, even if there is a bug in musl. Guenter
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
On Wed, May 25, 2022 at 1:42 AM Guo Ren wrote: > > On Mon, May 23, 2022 at 1:45 PM Guenter Roeck wrote: > > > > On Tue, Mar 22, 2022 at 10:40:03PM +0800, guo...@kernel.org wrote: > > > From: Guo Ren > > > > > > Adds initial skeletal COMPAT Kbuild (Running 32bit U-mode on > > > 64bit S-mode) support. > > > - Setup kconfig & dummy functions for compiling. > > > - Implement compat_start_thread by the way. > > > > > > Signed-off-by: Guo Ren > > > Signed-off-by: Guo Ren > > > Reviewed-by: Arnd Bergmann > > > Tested-by: Heiko Stuebner > > > Cc: Palmer Dabbelt > > > > With this patch in linux-next, all my riscv64 emulations crash. > > > > [ 11.600082] Run /sbin/init as init process > > [ 11.628561] init[1]: unhandled signal 11 code 0x1 at 0x > > in libc.so[ff8ad39000+a4000] > > [ 11.629398] CPU: 0 PID: 1 Comm: init Not tainted > > 5.18.0-rc7-next-20220520 #1 > > [ 11.629462] Hardware name: riscv-virtio,qemu (DT) > > [ 11.629546] epc : 00ff8ada1100 ra : 00ff8ada13c8 sp : > > 00ffc58199f0 > > [ 11.629586] gp : 00ff8ad39000 tp : 00ff8ade0998 t0 : > > > > [ 11.629598] t1 : 00ffc5819fd0 t2 : s0 : > > 00ff8ade0cc0 > > [ 11.629610] s1 : 00ff8ade0cc0 a0 : a1 : > > 00ffc5819a00 > > [ 11.629622] a2 : 0001 a3 : 001e a4 : > > 00ffc5819b00 > > [ 11.629634] a5 : 00ffc5819b00 a6 : a7 : > > > > [ 11.629645] s2 : 00ff8ade0ac8 s3 : 00ff8ade0ec8 s4 : > > 00ff8ade0728 > > [ 11.629656] s5 : 00ff8ade0a90 s6 : s7 : > > 00ffc5819e40 > > [ 11.629667] s8 : 00ff8ade0ca0 s9 : 00ff8addba50 s10: > > > > [ 11.629678] s11: t3 : 0002 t4 : > > 0001 > > [ 11.629688] t5 : 0002 t6 : > > [ 11.629699] status: 4020 badaddr: cause: > > 000d > > [ 11.633421] Kernel panic - not syncing: Attempted to kill init! > > exitcode=0x000b > > [ 11.633664] CPU: 0 PID: 1 Comm: init Not tainted > > 5.18.0-rc7-next-20220520 #1 > > [ 11.633784] Hardware name: riscv-virtio,qemu (DT) > > [ 11.633881] Call Trace: > > [ 11.633960] [] dump_backtrace+0x1c/0x24 > > [ 11.634162] [] show_stack+0x2c/0x38 > > [ 11.634274] [] dump_stack_lvl+0x60/0x8e > > [ 11.634386] [] dump_stack+0x14/0x1c > > [ 11.634491] [] panic+0x116/0x2e2 > > [ 11.634596] [] do_exit+0x7ce/0x7d4 > > [ 11.634707] [] do_group_exit+0x24/0x7c > > [ 11.634817] [] get_signal+0x7ee/0x830 > > [ 11.634924] [] do_notify_resume+0x6c/0x41c > > [ 11.635037] [] ret_from_exception+0x0/0x10 > The problem is come from "__dls3's vdso decode part in musl's > ldso/dynlink.c". The ehdr->e_phnum & ehdr->e_phentsize are wrong. > > I think the root cause is from musl's implementation with the wrong > elf parser. I would fix that soon. Not elf parser, it's "aux vector just past environ[]". I think I could solve this, but anyone who could help dig in is welcome. > > If you CONFIG_COMPAT=n, the bug would be bypassed. > > > > > Guenter > > > > --- > > # bad: [18ecd30af1a8402c162cca1bd58771c0e5be7815] Add linux-next specific > > files for 20220520 > > # good: [42226c989789d8da4af1de0c31070c96726d990c] Linux 5.18-rc7 > > git bisect start 'HEAD' 'v5.18-rc7' > > # bad: [f9b63740b666dd9887eb0282d21b5f65bb0cadd0] Merge branch 'master' of > > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git > > git bisect bad f9b63740b666dd9887eb0282d21b5f65bb0cadd0 > > # bad: [7db97132097c5973ff77466d0ee681650af653de] Merge branch 'for-next' > > of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux > > git bisect bad 7db97132097c5973ff77466d0ee681650af653de > > # good: [2b7d17d4b7c1ff40f58b0d32be40fc0bb6c582fb] soc: document merges > > git bisect good 2b7d17d4b7c1ff40f58b0d32be40fc0bb6c582fb > > # good: [69c9668f853fdd409bb8abbb37d615785510b29a] Merge branch 'clk-next' > > of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git > > git bisect good 69c9668f853fdd409bb8abbb37d615785510b29a > > # bad: [1577f290aa0d4c5b29c03c46ef52e4952a21bfbb] Merge branch 'for-next' > > of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git > > git bisect bad 1577f290aa0d4c5b29c03c46ef52e4952a21bfbb > > # good: [34f0971f8ca73d7e5502b4cf299788a9402120f7] powerpc/powernv/flash: > > Check OPAL flash calls exist before using > > git bisect good 34f0971f8ca73d7e5502b4cf299788a9402120f7 > > # good: [0349d7dfc70a26b3facd8ca97de34980d4b60954] Merge branch 'mips-next' > > of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git > > git bisect good 0349d7dfc70a26b3facd8ca97de34980d4b60954 > > # bad: [20bfb54d3b121699674c17a854c5ebc7a8f97d81] Merge branch 'for-next' > > of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git > > git bisect bad 20bfb54d3b121699674c17a854c5ebc7a8f97d81
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
On Mon, May 23, 2022 at 1:45 PM Guenter Roeck wrote: > > On Tue, Mar 22, 2022 at 10:40:03PM +0800, guo...@kernel.org wrote: > > From: Guo Ren > > > > Adds initial skeletal COMPAT Kbuild (Running 32bit U-mode on > > 64bit S-mode) support. > > - Setup kconfig & dummy functions for compiling. > > - Implement compat_start_thread by the way. > > > > Signed-off-by: Guo Ren > > Signed-off-by: Guo Ren > > Reviewed-by: Arnd Bergmann > > Tested-by: Heiko Stuebner > > Cc: Palmer Dabbelt > > With this patch in linux-next, all my riscv64 emulations crash. > > [ 11.600082] Run /sbin/init as init process > [ 11.628561] init[1]: unhandled signal 11 code 0x1 at 0x in > libc.so[ff8ad39000+a4000] > [ 11.629398] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 > #1 > [ 11.629462] Hardware name: riscv-virtio,qemu (DT) > [ 11.629546] epc : 00ff8ada1100 ra : 00ff8ada13c8 sp : > 00ffc58199f0 > [ 11.629586] gp : 00ff8ad39000 tp : 00ff8ade0998 t0 : > > [ 11.629598] t1 : 00ffc5819fd0 t2 : s0 : > 00ff8ade0cc0 > [ 11.629610] s1 : 00ff8ade0cc0 a0 : a1 : > 00ffc5819a00 > [ 11.629622] a2 : 0001 a3 : 001e a4 : > 00ffc5819b00 > [ 11.629634] a5 : 00ffc5819b00 a6 : a7 : > > [ 11.629645] s2 : 00ff8ade0ac8 s3 : 00ff8ade0ec8 s4 : > 00ff8ade0728 > [ 11.629656] s5 : 00ff8ade0a90 s6 : s7 : > 00ffc5819e40 > [ 11.629667] s8 : 00ff8ade0ca0 s9 : 00ff8addba50 s10: > > [ 11.629678] s11: t3 : 0002 t4 : > 0001 > [ 11.629688] t5 : 0002 t6 : > [ 11.629699] status: 4020 badaddr: cause: > 000d > [ 11.633421] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x000b > [ 11.633664] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 > #1 > [ 11.633784] Hardware name: riscv-virtio,qemu (DT) > [ 11.633881] Call Trace: > [ 11.633960] [] dump_backtrace+0x1c/0x24 > [ 11.634162] [] show_stack+0x2c/0x38 > [ 11.634274] [] dump_stack_lvl+0x60/0x8e > [ 11.634386] [] dump_stack+0x14/0x1c > [ 11.634491] [] panic+0x116/0x2e2 > [ 11.634596] [] do_exit+0x7ce/0x7d4 > [ 11.634707] [] do_group_exit+0x24/0x7c > [ 11.634817] [] get_signal+0x7ee/0x830 > [ 11.634924] [] do_notify_resume+0x6c/0x41c > [ 11.635037] [] ret_from_exception+0x0/0x10 The problem is come from "__dls3's vdso decode part in musl's ldso/dynlink.c". The ehdr->e_phnum & ehdr->e_phentsize are wrong. I think the root cause is from musl's implementation with the wrong elf parser. I would fix that soon. If you CONFIG_COMPAT=n, the bug would be bypassed. > > Guenter > > --- > # bad: [18ecd30af1a8402c162cca1bd58771c0e5be7815] Add linux-next specific > files for 20220520 > # good: [42226c989789d8da4af1de0c31070c96726d990c] Linux 5.18-rc7 > git bisect start 'HEAD' 'v5.18-rc7' > # bad: [f9b63740b666dd9887eb0282d21b5f65bb0cadd0] Merge branch 'master' of > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git > git bisect bad f9b63740b666dd9887eb0282d21b5f65bb0cadd0 > # bad: [7db97132097c5973ff77466d0ee681650af653de] Merge branch 'for-next' of > git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux > git bisect bad 7db97132097c5973ff77466d0ee681650af653de > # good: [2b7d17d4b7c1ff40f58b0d32be40fc0bb6c582fb] soc: document merges > git bisect good 2b7d17d4b7c1ff40f58b0d32be40fc0bb6c582fb > # good: [69c9668f853fdd409bb8abbb37d615785510b29a] Merge branch 'clk-next' of > git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git > git bisect good 69c9668f853fdd409bb8abbb37d615785510b29a > # bad: [1577f290aa0d4c5b29c03c46ef52e4952a21bfbb] Merge branch 'for-next' of > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git > git bisect bad 1577f290aa0d4c5b29c03c46ef52e4952a21bfbb > # good: [34f0971f8ca73d7e5502b4cf299788a9402120f7] powerpc/powernv/flash: > Check OPAL flash calls exist before using > git bisect good 34f0971f8ca73d7e5502b4cf299788a9402120f7 > # good: [0349d7dfc70a26b3facd8ca97de34980d4b60954] Merge branch 'mips-next' > of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git > git bisect good 0349d7dfc70a26b3facd8ca97de34980d4b60954 > # bad: [20bfb54d3b121699674c17a854c5ebc7a8f97d81] Merge branch 'for-next' of > git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git > git bisect bad 20bfb54d3b121699674c17a854c5ebc7a8f97d81 > # bad: [9be8459298eadb39b9fe9974b890239e9c123107] riscv: compat: Add COMPAT > Kbuild skeletal support > git bisect bad 9be8459298eadb39b9fe9974b890239e9c123107 > # good: [01abdfeac81b5f56062d0a78f2cdc805db937a75] riscv: compat: Support > TASK_SIZE for compat mode > git bisect good 01abdfeac81b5f56062d0a78f2cdc805db937a75 > # good: [f4b395e6f1a588ed6c9a30474e58cf6b27b65783]
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
Am Dienstag, 24. Mai 2022, 01:00:39 CEST schrieb Guenter Roeck:
> On Tue, May 24, 2022 at 12:40:06AM +0200, Heiko Stübner wrote:
> > Hi Guenter,
> >
> > Am Montag, 23. Mai 2022, 18:18:47 CEST schrieb Guenter Roeck:
> > > On 5/23/22 08:18, Guo Ren wrote:
> > > > I tested Palmer's branch, it's okay:
> > > > 8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a
> > > > bogus mmu-type on a no MMU kernel
> > > >
> > > > I also tested linux-next, it's okay:
> > > >
> > > > rv64_rootfs:
> > > > # uname -a
> > > > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT
> > > > 2022 riscv64 GNU/Linux
> > > > #
> > >
> > > That is is ok with one setup doesn't mean it is ok with
> > > all setups. It is not ok with my root file system (from
> > > https://github.com/groeck/linux-build-test/tree/master/rootfs/riscv64),
> > > with qemu v6.2.
> >
> > That is very true that it shouldn't fail on any existing (qemu-)platform,
> > but as I remember also testing Guo's series on both riscv32 and riscv64
> > qemu platforms in the past, I guess it would be really helpful to get more
> > information about the failing platform you're experiencing so that we can
> > find the source of the issue.
> >
> > As it looks like you both tested the same kernel source, I guess the only
> > differences could be in the qemu-version, kernel config and rootfs.
> > Is your rootfs something you can share or that can be rebuilt easily?
> >
> I provided a link to my root file system above. The link points to two
> root file systems, for initrd (cpio archive) and for ext2.
> I also mentioned above that I used qemu v6.2. And below I said
>
> > My root file system uses musl.
>
> I attached the buildroot configuration below. The buildroot version,
> if I remember correctly, was 2021.02.
>
> Kernel configuration is basically defconfig. However, I do see one
> detail that is possibly special in my configuration.
>
> # The latest kernel assumes SBI version 0.3, but that doesn't match qemu
> # at least up to version 6.2 and results in hangup/crashes during reboot
> # with sifive_u emulations.
> enable_config "${defconfig}" CONFIG_RISCV_SBI_V01
>
> Hope that helps,
Actually it doesn't seem rootfs-specific at all.
Merged was this v9, but the version I last tested was one of the earlier
ones, so it looks like something really broke meanwhile.
I tested both linux-next-20220524 and palmer's for-next on a very recent
qemu - master from april if I remember correctly together with a
Debian-based rootfs mounted as nfsroot inside qemu.
With CONFIG_COMPAT=y (aka using defconfig directly) I get:
[ 12.957612] VFS: Mounted root (nfs filesystem) on device 0:15.
[ 12.967260] devtmpfs: mounted
[ 13.101186] Freeing unused kernel image (initmem) memory: 2168K
[ 13.110914] Run /sbin/init as init process
[ 13.343810] Unable to handle kernel paging request at virtual address
ff60007265776f78
[ 13.347271] Oops [#1]
[ 13.347749] Modules linked in:
[ 13.348689] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-next-20220524 #1
[ 13.349864] Hardware name: riscv-virtio,qemu (DT)
[ 13.350706] epc : special_mapping_fault+0x4c/0x8e
[ 13.351639] ra : __do_fault+0x28/0x11c
[ 13.352311] epc : 801210e6 ra : 8011712a sp :
ff200060bd10
[ 13.353276] gp : 810df030 tp : ff60012a8000 t0 :
80008acc
[ 13.354063] t1 : 80c001d8 t2 : 80c00258 s0 :
ff200060bd20
[ 13.354886] s1 : ff200060bd68 a0 : ff60013165f0 a1 :
ff6001ec2450
[ 13.355675] a2 : ff200060bd68 a3 : a4 :
ff603f0337c8
[ 13.356822] a5 : ff60007265776f70 a6 : ff6001ec2450 a7 :
0007
[ 13.357689] s2 : ff6001ec2450 s3 : ff6001ec2450 s4 :
ff200060bd68
[ 13.358487] s5 : ff6001ec2450 s6 : 0254 s7 :
000c
[ 13.359305] s8 : 000f s9 : 000d s10:
ff6001e4c080
[ 13.360102] s11: 000d t3 : 00ffbbeab000 t4 :
6dff
[ 13.361557] t5 : 6e35 t6 : 000a
[ 13.362229] status: 00020120 badaddr: ff60007265776f78 cause:
000d
[ 13.363504] [] __do_fault+0x28/0x11c
[ 13.364464] [] __handle_mm_fault+0x71c/0x9ea
[ 13.365577] [] handle_mm_fault+0x82/0x136
[ 13.366275] [] do_page_fault+0x120/0x31c
[ 13.366906] [] ret_from_exception+0x0/0xc
[ 13.368763] ---[ end trace ]---
[ 13.368763] ---[ end trace ]---
[ 13.369598] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[ 13.369933] SMP: stopping secondary CPUs
Turning CONFIG_COMPAT off, results in the system booting normally again.
Heiko
> ---
> BR2_riscv=y
> BR2_TOOLCHAIN_BUILDROOT_MUSL=y
> BR2_KERNEL_HEADERS_4_19=y
> BR2_BINUTILS_VERSION_2_32_X=y
> BR2_TARGET_RUN_TESTSCRIPT=y
> BR2_SHUTDOWN_COMMAND_POWEROFF=y
> BR2_SYSTEM_DHCP="eth0"
> BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
>
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
Hi Guenter, Am Montag, 23. Mai 2022, 18:18:47 CEST schrieb Guenter Roeck: > On 5/23/22 08:18, Guo Ren wrote: > > I tested Palmer's branch, it's okay: > > 8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a > > bogus mmu-type on a no MMU kernel > > > > I also tested linux-next, it's okay: > > > > rv64_rootfs: > > # uname -a > > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT > > 2022 riscv64 GNU/Linux > > # > > That is is ok with one setup doesn't mean it is ok with > all setups. It is not ok with my root file system (from > https://github.com/groeck/linux-build-test/tree/master/rootfs/riscv64), > with qemu v6.2. That is very true that it shouldn't fail on any existing (qemu-)platform, but as I remember also testing Guo's series on both riscv32 and riscv64 qemu platforms in the past, I guess it would be really helpful to get more information about the failing platform you're experiencing so that we can find the source of the issue. As it looks like you both tested the same kernel source, I guess the only differences could be in the qemu-version, kernel config and rootfs. Is your rootfs something you can share or that can be rebuilt easily? Heiko > > # > > # > > # ls /lib > > ld-uClibc-1.0.39.so libatomic.so.1 libgcc_s.so > > ld-uClibc.so.0 libatomic.so.1.2.0 libgcc_s.so.1 > > ld-uClibc.so.1 libc.so.0libuClibc-1.0.39.so > > libatomic.so libc.so.1modules > > > > My root file system uses musl. > > Guenter > > > rv32_rootfs: > > buildroot login: root > > # uname -a > > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT > > 2022 riscv64 GNU/Linux > > # ls /lib > > ld-linux-riscv32-ilp32d.so.1 libm.so.6 > > libanl.so.1 libnss_dns.so.2 > > libatomic.so libnss_files.so.2 > > libatomic.so.1libpthread.so.0 > > libatomic.so.1.2.0libresolv.so.2 > > libc.so.6 librt.so.1 > > libcrypt.so.1 libthread_db.so.1 > > libdl.so.2libutil.so.1 > > libgcc_s.so modules > > libgcc_s.so.1 > > > > Here is my qemu version: > > commit 19f13a92cef8405052e0f73d5289f9e15474dad3 (HEAD -> > > riscv-to-apply.next, alistair/riscv-to-apply.next) > > Author: Tsukasa OI > > Date: Sun May 15 11:56:11 2022 +0900 > > > > target/riscv: Move/refactor ISA extension checks > > > > We should separate "check" and "configure" steps as possible. > > This commit separates both steps except vector/Zfinx-related checks. > > > > Signed-off-by: Tsukasa OI > > Reviewed-by: Alistair Francis > > Message-Id: > > > > Signed-off-by: Alistair Francis > > > > On Mon, May 23, 2022 at 1:45 PM Guenter Roeck wrote: > >> > >> On Tue, Mar 22, 2022 at 10:40:03PM +0800, guo...@kernel.org wrote: > >>> From: Guo Ren > >>> > >>> Adds initial skeletal COMPAT Kbuild (Running 32bit U-mode on > >>> 64bit S-mode) support. > >>> - Setup kconfig & dummy functions for compiling. > >>> - Implement compat_start_thread by the way. > >>> > >>> Signed-off-by: Guo Ren > >>> Signed-off-by: Guo Ren > >>> Reviewed-by: Arnd Bergmann > >>> Tested-by: Heiko Stuebner > >>> Cc: Palmer Dabbelt > >> > >> With this patch in linux-next, all my riscv64 emulations crash. > >> > >> [ 11.600082] Run /sbin/init as init process > >> [ 11.628561] init[1]: unhandled signal 11 code 0x1 at 0x > >> in libc.so[ff8ad39000+a4000] > >> [ 11.629398] CPU: 0 PID: 1 Comm: init Not tainted > >> 5.18.0-rc7-next-20220520 #1 > >> [ 11.629462] Hardware name: riscv-virtio,qemu (DT) > >> [ 11.629546] epc : 00ff8ada1100 ra : 00ff8ada13c8 sp : > >> 00ffc58199f0 > >> [ 11.629586] gp : 00ff8ad39000 tp : 00ff8ade0998 t0 : > >> > >> [ 11.629598] t1 : 00ffc5819fd0 t2 : s0 : > >> 00ff8ade0cc0 > >> [ 11.629610] s1 : 00ff8ade0cc0 a0 : a1 : > >> 00ffc5819a00 > >> [ 11.629622] a2 : 0001 a3 : 001e a4 : > >> 00ffc5819b00 > >> [ 11.629634] a5 : 00ffc5819b00 a6 : a7 : > >> > >> [ 11.629645] s2 : 00ff8ade0ac8 s3 : 00ff8ade0ec8 s4 : > >> 00ff8ade0728 > >> [ 11.629656] s5 : 00ff8ade0a90 s6 : s7 : > >> 00ffc5819e40 > >> [ 11.629667] s8 : 00ff8ade0ca0 s9 : 00ff8addba50 s10: > >> > >> [ 11.629678] s11: t3 : 0002 t4 : > >> 0001 > >> [ 11.629688] t5 : 0002 t6 : > >> [ 11.629699] status: 4020 badaddr: cause: > >> 000d > >> [ 11.633421] Kernel panic - not syncing: Attempted to kill init! > >> exitcode=0x000b > >> [ 11.633664] CPU: 0 PID: 1 Comm: init Not tainted > >> 5.18.0-rc7-next-20220520 #1 > >> [ 11.633784] Hardware name:
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
On Tue, May 24, 2022 at 12:40:06AM +0200, Heiko Stübner wrote:
> Hi Guenter,
>
> Am Montag, 23. Mai 2022, 18:18:47 CEST schrieb Guenter Roeck:
> > On 5/23/22 08:18, Guo Ren wrote:
> > > I tested Palmer's branch, it's okay:
> > > 8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a
> > > bogus mmu-type on a no MMU kernel
> > >
> > > I also tested linux-next, it's okay:
> > >
> > > rv64_rootfs:
> > > # uname -a
> > > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT
> > > 2022 riscv64 GNU/Linux
> > > #
> >
> > That is is ok with one setup doesn't mean it is ok with
> > all setups. It is not ok with my root file system (from
> > https://github.com/groeck/linux-build-test/tree/master/rootfs/riscv64),
> > with qemu v6.2.
>
> That is very true that it shouldn't fail on any existing (qemu-)platform,
> but as I remember also testing Guo's series on both riscv32 and riscv64
> qemu platforms in the past, I guess it would be really helpful to get more
> information about the failing platform you're experiencing so that we can
> find the source of the issue.
>
> As it looks like you both tested the same kernel source, I guess the only
> differences could be in the qemu-version, kernel config and rootfs.
> Is your rootfs something you can share or that can be rebuilt easily?
>
I provided a link to my root file system above. The link points to two
root file systems, for initrd (cpio archive) and for ext2.
I also mentioned above that I used qemu v6.2. And below I said
> My root file system uses musl.
I attached the buildroot configuration below. The buildroot version,
if I remember correctly, was 2021.02.
Kernel configuration is basically defconfig. However, I do see one
detail that is possibly special in my configuration.
# The latest kernel assumes SBI version 0.3, but that doesn't match qemu
# at least up to version 6.2 and results in hangup/crashes during reboot
# with sifive_u emulations.
enable_config "${defconfig}" CONFIG_RISCV_SBI_V01
Hope that helps,
Guenter
---
BR2_riscv=y
BR2_TOOLCHAIN_BUILDROOT_MUSL=y
BR2_KERNEL_HEADERS_4_19=y
BR2_BINUTILS_VERSION_2_32_X=y
BR2_TARGET_RUN_TESTSCRIPT=y
BR2_SHUTDOWN_COMMAND_POWEROFF=y
BR2_SYSTEM_DHCP="eth0"
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
BR2_PACKAGE_STRACE=y
BR2_PACKAGE_I2C_TOOLS=y
BR2_PACKAGE_PCIUTILS=y
BR2_PACKAGE_DTC=y
BR2_PACKAGE_DTC_PROGRAMS=y
BR2_PACKAGE_IPROUTE2=y
BR2_TARGET_ROOTFS_BTRFS=y
BR2_TARGET_ROOTFS_CPIO=y
BR2_TARGET_ROOTFS_CPIO_GZIP=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_SIZE="16M"
BR2_TARGET_ROOTFS_EXT2_GZIP=y
BR2_TARGET_ROOTFS_ISO_GZIP=y
BR2_TARGET_ROOTFS_SQUASHFS=y
# BR2_TARGET_ROOTFS_TAR is not set
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
On 5/23/22 08:18, Guo Ren wrote: I tested Palmer's branch, it's okay: 8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a bogus mmu-type on a no MMU kernel I also tested linux-next, it's okay: rv64_rootfs: # uname -a Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT 2022 riscv64 GNU/Linux # That is is ok with one setup doesn't mean it is ok with all setups. It is not ok with my root file system (from https://github.com/groeck/linux-build-test/tree/master/rootfs/riscv64), with qemu v6.2. # # # ls /lib ld-uClibc-1.0.39.so libatomic.so.1 libgcc_s.so ld-uClibc.so.0 libatomic.so.1.2.0 libgcc_s.so.1 ld-uClibc.so.1 libc.so.0libuClibc-1.0.39.so libatomic.so libc.so.1modules My root file system uses musl. Guenter rv32_rootfs: buildroot login: root # uname -a Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT 2022 riscv64 GNU/Linux # ls /lib ld-linux-riscv32-ilp32d.so.1 libm.so.6 libanl.so.1 libnss_dns.so.2 libatomic.so libnss_files.so.2 libatomic.so.1libpthread.so.0 libatomic.so.1.2.0libresolv.so.2 libc.so.6 librt.so.1 libcrypt.so.1 libthread_db.so.1 libdl.so.2libutil.so.1 libgcc_s.so modules libgcc_s.so.1 Here is my qemu version: commit 19f13a92cef8405052e0f73d5289f9e15474dad3 (HEAD -> riscv-to-apply.next, alistair/riscv-to-apply.next) Author: Tsukasa OI Date: Sun May 15 11:56:11 2022 +0900 target/riscv: Move/refactor ISA extension checks We should separate "check" and "configure" steps as possible. This commit separates both steps except vector/Zfinx-related checks. Signed-off-by: Tsukasa OI Reviewed-by: Alistair Francis Message-Id: Signed-off-by: Alistair Francis On Mon, May 23, 2022 at 1:45 PM Guenter Roeck wrote: On Tue, Mar 22, 2022 at 10:40:03PM +0800, guo...@kernel.org wrote: From: Guo Ren Adds initial skeletal COMPAT Kbuild (Running 32bit U-mode on 64bit S-mode) support. - Setup kconfig & dummy functions for compiling. - Implement compat_start_thread by the way. Signed-off-by: Guo Ren Signed-off-by: Guo Ren Reviewed-by: Arnd Bergmann Tested-by: Heiko Stuebner Cc: Palmer Dabbelt With this patch in linux-next, all my riscv64 emulations crash. [ 11.600082] Run /sbin/init as init process [ 11.628561] init[1]: unhandled signal 11 code 0x1 at 0x in libc.so[ff8ad39000+a4000] [ 11.629398] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 #1 [ 11.629462] Hardware name: riscv-virtio,qemu (DT) [ 11.629546] epc : 00ff8ada1100 ra : 00ff8ada13c8 sp : 00ffc58199f0 [ 11.629586] gp : 00ff8ad39000 tp : 00ff8ade0998 t0 : [ 11.629598] t1 : 00ffc5819fd0 t2 : s0 : 00ff8ade0cc0 [ 11.629610] s1 : 00ff8ade0cc0 a0 : a1 : 00ffc5819a00 [ 11.629622] a2 : 0001 a3 : 001e a4 : 00ffc5819b00 [ 11.629634] a5 : 00ffc5819b00 a6 : a7 : [ 11.629645] s2 : 00ff8ade0ac8 s3 : 00ff8ade0ec8 s4 : 00ff8ade0728 [ 11.629656] s5 : 00ff8ade0a90 s6 : s7 : 00ffc5819e40 [ 11.629667] s8 : 00ff8ade0ca0 s9 : 00ff8addba50 s10: [ 11.629678] s11: t3 : 0002 t4 : 0001 [ 11.629688] t5 : 0002 t6 : [ 11.629699] status: 4020 badaddr: cause: 000d [ 11.633421] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [ 11.633664] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 #1 [ 11.633784] Hardware name: riscv-virtio,qemu (DT) [ 11.633881] Call Trace: [ 11.633960] [] dump_backtrace+0x1c/0x24 [ 11.634162] [] show_stack+0x2c/0x38 [ 11.634274] [] dump_stack_lvl+0x60/0x8e [ 11.634386] [] dump_stack+0x14/0x1c [ 11.634491] [] panic+0x116/0x2e2 [ 11.634596] [] do_exit+0x7ce/0x7d4 [ 11.634707] [] do_group_exit+0x24/0x7c [ 11.634817] [] get_signal+0x7ee/0x830 [ 11.634924] [] do_notify_resume+0x6c/0x41c [ 11.635037] [] ret_from_exception+0x0/0x10 Guenter --- # bad: [18ecd30af1a8402c162cca1bd58771c0e5be7815] Add linux-next specific files for 20220520 # good: [42226c989789d8da4af1de0c31070c96726d990c] Linux 5.18-rc7 git bisect start 'HEAD' 'v5.18-rc7' # bad: [f9b63740b666dd9887eb0282d21b5f65bb0cadd0] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git git bisect bad f9b63740b666dd9887eb0282d21b5f65bb0cadd0 # bad: [7db97132097c5973ff77466d0ee681650af653de] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux git bisect bad 7db97132097c5973ff77466d0ee681650af653de # good: [2b7d17d4b7c1ff40f58b0d32be40fc0bb6c582fb] soc:
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
I tested Palmer's branch, it's okay: 8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a bogus mmu-type on a no MMU kernel I also tested linux-next, it's okay: rv64_rootfs: # uname -a Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT 2022 riscv64 GNU/Linux # # # # ls /lib ld-uClibc-1.0.39.so libatomic.so.1 libgcc_s.so ld-uClibc.so.0 libatomic.so.1.2.0 libgcc_s.so.1 ld-uClibc.so.1 libc.so.0libuClibc-1.0.39.so libatomic.so libc.so.1modules rv32_rootfs: buildroot login: root # uname -a Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT 2022 riscv64 GNU/Linux # ls /lib ld-linux-riscv32-ilp32d.so.1 libm.so.6 libanl.so.1 libnss_dns.so.2 libatomic.so libnss_files.so.2 libatomic.so.1libpthread.so.0 libatomic.so.1.2.0libresolv.so.2 libc.so.6 librt.so.1 libcrypt.so.1 libthread_db.so.1 libdl.so.2libutil.so.1 libgcc_s.so modules libgcc_s.so.1 Here is my qemu version: commit 19f13a92cef8405052e0f73d5289f9e15474dad3 (HEAD -> riscv-to-apply.next, alistair/riscv-to-apply.next) Author: Tsukasa OI Date: Sun May 15 11:56:11 2022 +0900 target/riscv: Move/refactor ISA extension checks We should separate "check" and "configure" steps as possible. This commit separates both steps except vector/Zfinx-related checks. Signed-off-by: Tsukasa OI Reviewed-by: Alistair Francis Message-Id: Signed-off-by: Alistair Francis On Mon, May 23, 2022 at 1:45 PM Guenter Roeck wrote: > > On Tue, Mar 22, 2022 at 10:40:03PM +0800, guo...@kernel.org wrote: > > From: Guo Ren > > > > Adds initial skeletal COMPAT Kbuild (Running 32bit U-mode on > > 64bit S-mode) support. > > - Setup kconfig & dummy functions for compiling. > > - Implement compat_start_thread by the way. > > > > Signed-off-by: Guo Ren > > Signed-off-by: Guo Ren > > Reviewed-by: Arnd Bergmann > > Tested-by: Heiko Stuebner > > Cc: Palmer Dabbelt > > With this patch in linux-next, all my riscv64 emulations crash. > > [ 11.600082] Run /sbin/init as init process > [ 11.628561] init[1]: unhandled signal 11 code 0x1 at 0x in > libc.so[ff8ad39000+a4000] > [ 11.629398] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 > #1 > [ 11.629462] Hardware name: riscv-virtio,qemu (DT) > [ 11.629546] epc : 00ff8ada1100 ra : 00ff8ada13c8 sp : > 00ffc58199f0 > [ 11.629586] gp : 00ff8ad39000 tp : 00ff8ade0998 t0 : > > [ 11.629598] t1 : 00ffc5819fd0 t2 : s0 : > 00ff8ade0cc0 > [ 11.629610] s1 : 00ff8ade0cc0 a0 : a1 : > 00ffc5819a00 > [ 11.629622] a2 : 0001 a3 : 001e a4 : > 00ffc5819b00 > [ 11.629634] a5 : 00ffc5819b00 a6 : a7 : > > [ 11.629645] s2 : 00ff8ade0ac8 s3 : 00ff8ade0ec8 s4 : > 00ff8ade0728 > [ 11.629656] s5 : 00ff8ade0a90 s6 : s7 : > 00ffc5819e40 > [ 11.629667] s8 : 00ff8ade0ca0 s9 : 00ff8addba50 s10: > > [ 11.629678] s11: t3 : 0002 t4 : > 0001 > [ 11.629688] t5 : 0002 t6 : > [ 11.629699] status: 4020 badaddr: cause: > 000d > [ 11.633421] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x000b > [ 11.633664] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 > #1 > [ 11.633784] Hardware name: riscv-virtio,qemu (DT) > [ 11.633881] Call Trace: > [ 11.633960] [] dump_backtrace+0x1c/0x24 > [ 11.634162] [] show_stack+0x2c/0x38 > [ 11.634274] [] dump_stack_lvl+0x60/0x8e > [ 11.634386] [] dump_stack+0x14/0x1c > [ 11.634491] [] panic+0x116/0x2e2 > [ 11.634596] [] do_exit+0x7ce/0x7d4 > [ 11.634707] [] do_group_exit+0x24/0x7c > [ 11.634817] [] get_signal+0x7ee/0x830 > [ 11.634924] [] do_notify_resume+0x6c/0x41c > [ 11.635037] [] ret_from_exception+0x0/0x10 > > Guenter > > --- > # bad: [18ecd30af1a8402c162cca1bd58771c0e5be7815] Add linux-next specific > files for 20220520 > # good: [42226c989789d8da4af1de0c31070c96726d990c] Linux 5.18-rc7 > git bisect start 'HEAD' 'v5.18-rc7' > # bad: [f9b63740b666dd9887eb0282d21b5f65bb0cadd0] Merge branch 'master' of > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git > git bisect bad f9b63740b666dd9887eb0282d21b5f65bb0cadd0 > # bad: [7db97132097c5973ff77466d0ee681650af653de] Merge branch 'for-next' of > git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux > git bisect bad 7db97132097c5973ff77466d0ee681650af653de > # good: [2b7d17d4b7c1ff40f58b0d32be40fc0bb6c582fb] soc: document merges > git bisect good 2b7d17d4b7c1ff40f58b0d32be40fc0bb6c582fb > # good: [69c9668f853fdd409bb8abbb37d615785510b29a]
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
On Tue, Mar 22, 2022 at 10:40:03PM +0800, guo...@kernel.org wrote: > From: Guo Ren > > Adds initial skeletal COMPAT Kbuild (Running 32bit U-mode on > 64bit S-mode) support. > - Setup kconfig & dummy functions for compiling. > - Implement compat_start_thread by the way. > > Signed-off-by: Guo Ren > Signed-off-by: Guo Ren > Reviewed-by: Arnd Bergmann > Tested-by: Heiko Stuebner > Cc: Palmer Dabbelt With this patch in linux-next, all my riscv64 emulations crash. [ 11.600082] Run /sbin/init as init process [ 11.628561] init[1]: unhandled signal 11 code 0x1 at 0x in libc.so[ff8ad39000+a4000] [ 11.629398] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 #1 [ 11.629462] Hardware name: riscv-virtio,qemu (DT) [ 11.629546] epc : 00ff8ada1100 ra : 00ff8ada13c8 sp : 00ffc58199f0 [ 11.629586] gp : 00ff8ad39000 tp : 00ff8ade0998 t0 : [ 11.629598] t1 : 00ffc5819fd0 t2 : s0 : 00ff8ade0cc0 [ 11.629610] s1 : 00ff8ade0cc0 a0 : a1 : 00ffc5819a00 [ 11.629622] a2 : 0001 a3 : 001e a4 : 00ffc5819b00 [ 11.629634] a5 : 00ffc5819b00 a6 : a7 : [ 11.629645] s2 : 00ff8ade0ac8 s3 : 00ff8ade0ec8 s4 : 00ff8ade0728 [ 11.629656] s5 : 00ff8ade0a90 s6 : s7 : 00ffc5819e40 [ 11.629667] s8 : 00ff8ade0ca0 s9 : 00ff8addba50 s10: [ 11.629678] s11: t3 : 0002 t4 : 0001 [ 11.629688] t5 : 0002 t6 : [ 11.629699] status: 4020 badaddr: cause: 000d [ 11.633421] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [ 11.633664] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 #1 [ 11.633784] Hardware name: riscv-virtio,qemu (DT) [ 11.633881] Call Trace: [ 11.633960] [] dump_backtrace+0x1c/0x24 [ 11.634162] [] show_stack+0x2c/0x38 [ 11.634274] [] dump_stack_lvl+0x60/0x8e [ 11.634386] [] dump_stack+0x14/0x1c [ 11.634491] [] panic+0x116/0x2e2 [ 11.634596] [] do_exit+0x7ce/0x7d4 [ 11.634707] [] do_group_exit+0x24/0x7c [ 11.634817] [] get_signal+0x7ee/0x830 [ 11.634924] [] do_notify_resume+0x6c/0x41c [ 11.635037] [] ret_from_exception+0x0/0x10 Guenter --- # bad: [18ecd30af1a8402c162cca1bd58771c0e5be7815] Add linux-next specific files for 20220520 # good: [42226c989789d8da4af1de0c31070c96726d990c] Linux 5.18-rc7 git bisect start 'HEAD' 'v5.18-rc7' # bad: [f9b63740b666dd9887eb0282d21b5f65bb0cadd0] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git git bisect bad f9b63740b666dd9887eb0282d21b5f65bb0cadd0 # bad: [7db97132097c5973ff77466d0ee681650af653de] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux git bisect bad 7db97132097c5973ff77466d0ee681650af653de # good: [2b7d17d4b7c1ff40f58b0d32be40fc0bb6c582fb] soc: document merges git bisect good 2b7d17d4b7c1ff40f58b0d32be40fc0bb6c582fb # good: [69c9668f853fdd409bb8abbb37d615785510b29a] Merge branch 'clk-next' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git git bisect good 69c9668f853fdd409bb8abbb37d615785510b29a # bad: [1577f290aa0d4c5b29c03c46ef52e4952a21bfbb] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git git bisect bad 1577f290aa0d4c5b29c03c46ef52e4952a21bfbb # good: [34f0971f8ca73d7e5502b4cf299788a9402120f7] powerpc/powernv/flash: Check OPAL flash calls exist before using git bisect good 34f0971f8ca73d7e5502b4cf299788a9402120f7 # good: [0349d7dfc70a26b3facd8ca97de34980d4b60954] Merge branch 'mips-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git git bisect good 0349d7dfc70a26b3facd8ca97de34980d4b60954 # bad: [20bfb54d3b121699674c17a854c5ebc7a8f97d81] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git git bisect bad 20bfb54d3b121699674c17a854c5ebc7a8f97d81 # bad: [9be8459298eadb39b9fe9974b890239e9c123107] riscv: compat: Add COMPAT Kbuild skeletal support git bisect bad 9be8459298eadb39b9fe9974b890239e9c123107 # good: [01abdfeac81b5f56062d0a78f2cdc805db937a75] riscv: compat: Support TASK_SIZE for compat mode git bisect good 01abdfeac81b5f56062d0a78f2cdc805db937a75 # good: [f4b395e6f1a588ed6c9a30474e58cf6b27b65783] riscv: compat: Add hw capability check for elf git bisect good f4b395e6f1a588ed6c9a30474e58cf6b27b65783 # good: [3092eb45637573c5e435fbf5eaf9516316e5f9c6] riscv: compat: vdso: Add setup additional pages implementation git bisect good 3092eb45637573c5e435fbf5eaf9516316e5f9c6 # good: [4608c159594fb40a5101357d4f614fdde9ce1fdb] riscv: compat: ptrace: Add compat_arch_ptrace implement git bisect good 4608c159594fb40a5101357d4f614fdde9ce1fdb # first bad commit: [9be8459298eadb39b9fe9974b890239e9c123107] riscv: compat: Add COMPAT
