| Message ID | 20220322144003.2357128-21-guoren@kernel.org |
|---|---|
| State | New |
| Headers | show |
| Series | riscv: compat: Add COMPAT Kbuild skeletal support | expand |
On Tue, Mar 22, 2022 at 10:40:03PM +0800, guoren@kernel.org wrote: > From: Guo Ren <guoren@linux.alibaba.com> > > 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 <guoren@linux.alibaba.com> > Signed-off-by: Guo Ren <guoren@kernel.org> > Reviewed-by: Arnd Bergmann <arnd@arndb.de> > Tested-by: Heiko Stuebner <heiko@sntech.de> > Cc: Palmer Dabbelt <palmer@dabbelt.com> 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 0x0000000000000000 in libc.so[ffffff8ad39000+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 : 00ffffff8ada1100 ra : 00ffffff8ada13c8 sp : 00ffffffc58199f0 [ 11.629586] gp : 00ffffff8ad39000 tp : 00ffffff8ade0998 t0 : ffffffffffffffff [ 11.629598] t1 : 00ffffffc5819fd0 t2 : 0000000000000000 s0 : 00ffffff8ade0cc0 [ 11.629610] s1 : 00ffffff8ade0cc0 a0 : 0000000000000000 a1 : 00ffffffc5819a00 [ 11.629622] a2 : 0000000000000001 a3 : 000000000000001e a4 : 00ffffffc5819b00 [ 11.629634] a5 : 00ffffffc5819b00 a6 : 0000000000000000 a7 : 0000000000000000 [ 11.629645] s2 : 00ffffff8ade0ac8 s3 : 00ffffff8ade0ec8 s4 : 00ffffff8ade0728 [ 11.629656] s5 : 00ffffff8ade0a90 s6 : 0000000000000000 s7 : 00ffffffc5819e40 [ 11.629667] s8 : 00ffffff8ade0ca0 s9 : 00ffffff8addba50 s10: 0000000000000000 [ 11.629678] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000001 [ 11.629688] t5 : 0000000000020000 t6 : ffffffffffffffff [ 11.629699] status: 0000000000004020 badaddr: 0000000000000000 cause: 000000000000000d [ 11.633421] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 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] [<ffffffff80005e72>] dump_backtrace+0x1c/0x24 [ 11.634162] [<ffffffff809aa9ec>] show_stack+0x2c/0x38 [ 11.634274] [<ffffffff809b8482>] dump_stack_lvl+0x60/0x8e [ 11.634386] [<ffffffff809b84c4>] dump_stack+0x14/0x1c [ 11.634491] [<ffffffff809aaca0>] panic+0x116/0x2e2 [ 11.634596] [<ffffffff80015540>] do_exit+0x7ce/0x7d4 [ 11.634707] [<ffffffff80015666>] do_group_exit+0x24/0x7c [ 11.634817] [<ffffffff80022294>] get_signal+0x7ee/0x830 [ 11.634924] [<ffffffff800051c0>] do_notify_resume+0x6c/0x41c [ 11.635037] [<ffffffff80003ad4>] 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 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.0 libuClibc-1.0.39.so
libatomic.so libc.so.1 modules
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.1 libpthread.so.0
libatomic.so.1.2.0 libresolv.so.2
libc.so.6 librt.so.1
libcrypt.so.1 libthread_db.so.1
libdl.so.2 libutil.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 <research_trasio@irq.a4lg.com>
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 <research_trasio@irq.a4lg.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id:
<c3145fa37a529484cf3047c8cb9841e9effad4b0.1652583332.git.research_trasio@irq.a4lg.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
On Mon, May 23, 2022 at 1:45 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Tue, Mar 22, 2022 at 10:40:03PM +0800, guoren@kernel.org wrote:
> > From: Guo Ren <guoren@linux.alibaba.com>
> >
> > 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 <guoren@linux.alibaba.com>
> > Signed-off-by: Guo Ren <guoren@kernel.org>
> > Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> > Tested-by: Heiko Stuebner <heiko@sntech.de>
> > Cc: Palmer Dabbelt <palmer@dabbelt.com>
>
> 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 0x0000000000000000 in libc.so[ffffff8ad39000+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 : 00ffffff8ada1100 ra : 00ffffff8ada13c8 sp : 00ffffffc58199f0
> [ 11.629586] gp : 00ffffff8ad39000 tp : 00ffffff8ade0998 t0 : ffffffffffffffff
> [ 11.629598] t1 : 00ffffffc5819fd0 t2 : 0000000000000000 s0 : 00ffffff8ade0cc0
> [ 11.629610] s1 : 00ffffff8ade0cc0 a0 : 0000000000000000 a1 : 00ffffffc5819a00
> [ 11.629622] a2 : 0000000000000001 a3 : 000000000000001e a4 : 00ffffffc5819b00
> [ 11.629634] a5 : 00ffffffc5819b00 a6 : 0000000000000000 a7 : 0000000000000000
> [ 11.629645] s2 : 00ffffff8ade0ac8 s3 : 00ffffff8ade0ec8 s4 : 00ffffff8ade0728
> [ 11.629656] s5 : 00ffffff8ade0a90 s6 : 0000000000000000 s7 : 00ffffffc5819e40
> [ 11.629667] s8 : 00ffffff8ade0ca0 s9 : 00ffffff8addba50 s10: 0000000000000000
> [ 11.629678] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000001
> [ 11.629688] t5 : 0000000000020000 t6 : ffffffffffffffff
> [ 11.629699] status: 0000000000004020 badaddr: 0000000000000000 cause: 000000000000000d
> [ 11.633421] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [ 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] [<ffffffff80005e72>] dump_backtrace+0x1c/0x24
> [ 11.634162] [<ffffffff809aa9ec>] show_stack+0x2c/0x38
> [ 11.634274] [<ffffffff809b8482>] dump_stack_lvl+0x60/0x8e
> [ 11.634386] [<ffffffff809b84c4>] dump_stack+0x14/0x1c
> [ 11.634491] [<ffffffff809aaca0>] panic+0x116/0x2e2
> [ 11.634596] [<ffffffff80015540>] do_exit+0x7ce/0x7d4
> [ 11.634707] [<ffffffff80015666>] do_group_exit+0x24/0x7c
> [ 11.634817] [<ffffffff80022294>] get_signal+0x7ee/0x830
> [ 11.634924] [<ffffffff800051c0>] do_notify_resume+0x6c/0x41c
> [ 11.635037] [<ffffffff80003ad4>] 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 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.0 libuClibc-1.0.39.so > libatomic.so libc.so.1 modules > 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.1 libpthread.so.0 > libatomic.so.1.2.0 libresolv.so.2 > libc.so.6 librt.so.1 > libcrypt.so.1 libthread_db.so.1 > libdl.so.2 libutil.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 <research_trasio@irq.a4lg.com> > 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 <research_trasio@irq.a4lg.com> > Reviewed-by: Alistair Francis <alistair.francis@wdc.com> > Message-Id: > <c3145fa37a529484cf3047c8cb9841e9effad4b0.1652583332.git.research_trasio@irq.a4lg.com> > Signed-off-by: Alistair Francis <alistair.francis@wdc.com> > > On Mon, May 23, 2022 at 1:45 PM Guenter Roeck <linux@roeck-us.net> wrote: >> >> On Tue, Mar 22, 2022 at 10:40:03PM +0800, guoren@kernel.org wrote: >>> From: Guo Ren <guoren@linux.alibaba.com> >>> >>> 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 <guoren@linux.alibaba.com> >>> Signed-off-by: Guo Ren <guoren@kernel.org> >>> Reviewed-by: Arnd Bergmann <arnd@arndb.de> >>> Tested-by: Heiko Stuebner <heiko@sntech.de> >>> Cc: Palmer Dabbelt <palmer@dabbelt.com> >> >> 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 0x0000000000000000 in libc.so[ffffff8ad39000+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 : 00ffffff8ada1100 ra : 00ffffff8ada13c8 sp : 00ffffffc58199f0 >> [ 11.629586] gp : 00ffffff8ad39000 tp : 00ffffff8ade0998 t0 : ffffffffffffffff >> [ 11.629598] t1 : 00ffffffc5819fd0 t2 : 0000000000000000 s0 : 00ffffff8ade0cc0 >> [ 11.629610] s1 : 00ffffff8ade0cc0 a0 : 0000000000000000 a1 : 00ffffffc5819a00 >> [ 11.629622] a2 : 0000000000000001 a3 : 000000000000001e a4 : 00ffffffc5819b00 >> [ 11.629634] a5 : 00ffffffc5819b00 a6 : 0000000000000000 a7 : 0000000000000000 >> [ 11.629645] s2 : 00ffffff8ade0ac8 s3 : 00ffffff8ade0ec8 s4 : 00ffffff8ade0728 >> [ 11.629656] s5 : 00ffffff8ade0a90 s6 : 0000000000000000 s7 : 00ffffffc5819e40 >> [ 11.629667] s8 : 00ffffff8ade0ca0 s9 : 00ffffff8addba50 s10: 0000000000000000 >> [ 11.629678] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000001 >> [ 11.629688] t5 : 0000000000020000 t6 : ffffffffffffffff >> [ 11.629699] status: 0000000000004020 badaddr: 0000000000000000 cause: 000000000000000d >> [ 11.633421] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b >> [ 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] [<ffffffff80005e72>] dump_backtrace+0x1c/0x24 >> [ 11.634162] [<ffffffff809aa9ec>] show_stack+0x2c/0x38 >> [ 11.634274] [<ffffffff809b8482>] dump_stack_lvl+0x60/0x8e >> [ 11.634386] [<ffffffff809b84c4>] dump_stack+0x14/0x1c >> [ 11.634491] [<ffffffff809aaca0>] panic+0x116/0x2e2 >> [ 11.634596] [<ffffffff80015540>] do_exit+0x7ce/0x7d4 >> [ 11.634707] [<ffffffff80015666>] do_group_exit+0x24/0x7c >> [ 11.634817] [<ffffffff80022294>] get_signal+0x7ee/0x830 >> [ 11.634924] [<ffffffff800051c0>] do_notify_resume+0x6c/0x41c >> [ 11.635037] [<ffffffff80003ad4>] 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 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.0 libuClibc-1.0.39.so > > libatomic.so libc.so.1 modules > > > > 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.1 libpthread.so.0 > > libatomic.so.1.2.0 libresolv.so.2 > > libc.so.6 librt.so.1 > > libcrypt.so.1 libthread_db.so.1 > > libdl.so.2 libutil.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 <research_trasio@irq.a4lg.com> > > 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 <research_trasio@irq.a4lg.com> > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com> > > Message-Id: > > <c3145fa37a529484cf3047c8cb9841e9effad4b0.1652583332.git.research_trasio@irq.a4lg.com> > > Signed-off-by: Alistair Francis <alistair.francis@wdc.com> > > > > On Mon, May 23, 2022 at 1:45 PM Guenter Roeck <linux@roeck-us.net> wrote: > >> > >> On Tue, Mar 22, 2022 at 10:40:03PM +0800, guoren@kernel.org wrote: > >>> From: Guo Ren <guoren@linux.alibaba.com> > >>> > >>> 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 <guoren@linux.alibaba.com> > >>> Signed-off-by: Guo Ren <guoren@kernel.org> > >>> Reviewed-by: Arnd Bergmann <arnd@arndb.de> > >>> Tested-by: Heiko Stuebner <heiko@sntech.de> > >>> Cc: Palmer Dabbelt <palmer@dabbelt.com> > >> > >> 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 0x0000000000000000 in libc.so[ffffff8ad39000+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 : 00ffffff8ada1100 ra : 00ffffff8ada13c8 sp : 00ffffffc58199f0 > >> [ 11.629586] gp : 00ffffff8ad39000 tp : 00ffffff8ade0998 t0 : ffffffffffffffff > >> [ 11.629598] t1 : 00ffffffc5819fd0 t2 : 0000000000000000 s0 : 00ffffff8ade0cc0 > >> [ 11.629610] s1 : 00ffffff8ade0cc0 a0 : 0000000000000000 a1 : 00ffffffc5819a00 > >> [ 11.629622] a2 : 0000000000000001 a3 : 000000000000001e a4 : 00ffffffc5819b00 > >> [ 11.629634] a5 : 00ffffffc5819b00 a6 : 0000000000000000 a7 : 0000000000000000 > >> [ 11.629645] s2 : 00ffffff8ade0ac8 s3 : 00ffffff8ade0ec8 s4 : 00ffffff8ade0728 > >> [ 11.629656] s5 : 00ffffff8ade0a90 s6 : 0000000000000000 s7 : 00ffffffc5819e40 > >> [ 11.629667] s8 : 00ffffff8ade0ca0 s9 : 00ffffff8addba50 s10: 0000000000000000 > >> [ 11.629678] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000001 > >> [ 11.629688] t5 : 0000000000020000 t6 : ffffffffffffffff > >> [ 11.629699] status: 0000000000004020 badaddr: 0000000000000000 cause: 000000000000000d > >> [ 11.633421] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b > >> [ 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] [<ffffffff80005e72>] dump_backtrace+0x1c/0x24 > >> [ 11.634162] [<ffffffff809aa9ec>] show_stack+0x2c/0x38 > >> [ 11.634274] [<ffffffff809b8482>] dump_stack_lvl+0x60/0x8e > >> [ 11.634386] [<ffffffff809b84c4>] dump_stack+0x14/0x1c > >> [ 11.634491] [<ffffffff809aaca0>] panic+0x116/0x2e2 > >> [ 11.634596] [<ffffffff80015540>] do_exit+0x7ce/0x7d4 > >> [ 11.634707] [<ffffffff80015666>] do_group_exit+0x24/0x7c > >> [ 11.634817] [<ffffffff80022294>] get_signal+0x7ee/0x830 > >> [ 11.634924] [<ffffffff800051c0>] do_notify_resume+0x6c/0x41c > >> [ 11.635037] [<ffffffff80003ad4>] 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 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
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 : ffffffff801210e6 ra : ffffffff8011712a sp : ff2000000060bd10 [ 13.353276] gp : ffffffff810df030 tp : ff600000012a8000 t0 : ffffffff80008acc [ 13.354063] t1 : ffffffff80c001d8 t2 : ffffffff80c00258 s0 : ff2000000060bd20 [ 13.354886] s1 : ff2000000060bd68 a0 : ff600000013165f0 a1 : ff60000001ec2450 [ 13.355675] a2 : ff2000000060bd68 a3 : 0000000000000000 a4 : ff6000003f0337c8 [ 13.356822] a5 : ff60007265776f70 a6 : ff60000001ec2450 a7 : 0000000000000007 [ 13.357689] s2 : ff60000001ec2450 s3 : ff60000001ec2450 s4 : ff2000000060bd68 [ 13.358487] s5 : ff60000001ec2450 s6 : 0000000000000254 s7 : 000000000000000c [ 13.359305] s8 : 000000000000000f s9 : 000000000000000d s10: ff60000001e4c080 [ 13.360102] s11: 000000000000000d t3 : 00ffffffbbeab000 t4 : 000000006ffffdff [ 13.361557] t5 : 000000006ffffe35 t6 : 000000000000000a [ 13.362229] status: 0000000200000120 badaddr: ff60007265776f78 cause: 000000000000000d [ 13.363504] [<ffffffff8011712a>] __do_fault+0x28/0x11c [ 13.364464] [<ffffffff8011b346>] __handle_mm_fault+0x71c/0x9ea [ 13.365577] [<ffffffff8011b696>] handle_mm_fault+0x82/0x136 [ 13.366275] [<ffffffff80008bec>] do_page_fault+0x120/0x31c [ 13.366906] [<ffffffff800032f4>] ret_from_exception+0x0/0xc [ 13.368763] ---[ end trace 0000000000000000 ]--- [ 13.368763] ---[ end trace 0000000000000000 ]--- [ 13.369598] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 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 > 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 > >
On Mon, May 23, 2022 at 1:45 PM Guenter Roeck <linux@roeck-us.net> wrote: > > On Tue, Mar 22, 2022 at 10:40:03PM +0800, guoren@kernel.org wrote: > > From: Guo Ren <guoren@linux.alibaba.com> > > > > 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 <guoren@linux.alibaba.com> > > Signed-off-by: Guo Ren <guoren@kernel.org> > > Reviewed-by: Arnd Bergmann <arnd@arndb.de> > > Tested-by: Heiko Stuebner <heiko@sntech.de> > > Cc: Palmer Dabbelt <palmer@dabbelt.com> > > 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 0x0000000000000000 in libc.so[ffffff8ad39000+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 : 00ffffff8ada1100 ra : 00ffffff8ada13c8 sp : 00ffffffc58199f0 > [ 11.629586] gp : 00ffffff8ad39000 tp : 00ffffff8ade0998 t0 : ffffffffffffffff > [ 11.629598] t1 : 00ffffffc5819fd0 t2 : 0000000000000000 s0 : 00ffffff8ade0cc0 > [ 11.629610] s1 : 00ffffff8ade0cc0 a0 : 0000000000000000 a1 : 00ffffffc5819a00 > [ 11.629622] a2 : 0000000000000001 a3 : 000000000000001e a4 : 00ffffffc5819b00 > [ 11.629634] a5 : 00ffffffc5819b00 a6 : 0000000000000000 a7 : 0000000000000000 > [ 11.629645] s2 : 00ffffff8ade0ac8 s3 : 00ffffff8ade0ec8 s4 : 00ffffff8ade0728 > [ 11.629656] s5 : 00ffffff8ade0a90 s6 : 0000000000000000 s7 : 00ffffffc5819e40 > [ 11.629667] s8 : 00ffffff8ade0ca0 s9 : 00ffffff8addba50 s10: 0000000000000000 > [ 11.629678] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000001 > [ 11.629688] t5 : 0000000000020000 t6 : ffffffffffffffff > [ 11.629699] status: 0000000000004020 badaddr: 0000000000000000 cause: 000000000000000d > [ 11.633421] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b > [ 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] [<ffffffff80005e72>] dump_backtrace+0x1c/0x24 > [ 11.634162] [<ffffffff809aa9ec>] show_stack+0x2c/0x38 > [ 11.634274] [<ffffffff809b8482>] dump_stack_lvl+0x60/0x8e > [ 11.634386] [<ffffffff809b84c4>] dump_stack+0x14/0x1c > [ 11.634491] [<ffffffff809aaca0>] panic+0x116/0x2e2 > [ 11.634596] [<ffffffff80015540>] do_exit+0x7ce/0x7d4 > [ 11.634707] [<ffffffff80015666>] do_group_exit+0x24/0x7c > [ 11.634817] [<ffffffff80022294>] get_signal+0x7ee/0x830 > [ 11.634924] [<ffffffff800051c0>] do_notify_resume+0x6c/0x41c > [ 11.635037] [<ffffffff80003ad4>] 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] 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 Kbuild skeletal support
On Wed, May 25, 2022 at 1:42 AM Guo Ren <guoren@kernel.org> wrote: > > On Mon, May 23, 2022 at 1:45 PM Guenter Roeck <linux@roeck-us.net> wrote: > > > > On Tue, Mar 22, 2022 at 10:40:03PM +0800, guoren@kernel.org wrote: > > > From: Guo Ren <guoren@linux.alibaba.com> > > > > > > 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 <guoren@linux.alibaba.com> > > > Signed-off-by: Guo Ren <guoren@kernel.org> > > > Reviewed-by: Arnd Bergmann <arnd@arndb.de> > > > Tested-by: Heiko Stuebner <heiko@sntech.de> > > > Cc: Palmer Dabbelt <palmer@dabbelt.com> > > > > 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 0x0000000000000000 in libc.so[ffffff8ad39000+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 : 00ffffff8ada1100 ra : 00ffffff8ada13c8 sp : 00ffffffc58199f0 > > [ 11.629586] gp : 00ffffff8ad39000 tp : 00ffffff8ade0998 t0 : ffffffffffffffff > > [ 11.629598] t1 : 00ffffffc5819fd0 t2 : 0000000000000000 s0 : 00ffffff8ade0cc0 > > [ 11.629610] s1 : 00ffffff8ade0cc0 a0 : 0000000000000000 a1 : 00ffffffc5819a00 > > [ 11.629622] a2 : 0000000000000001 a3 : 000000000000001e a4 : 00ffffffc5819b00 > > [ 11.629634] a5 : 00ffffffc5819b00 a6 : 0000000000000000 a7 : 0000000000000000 > > [ 11.629645] s2 : 00ffffff8ade0ac8 s3 : 00ffffff8ade0ec8 s4 : 00ffffff8ade0728 > > [ 11.629656] s5 : 00ffffff8ade0a90 s6 : 0000000000000000 s7 : 00ffffffc5819e40 > > [ 11.629667] s8 : 00ffffff8ade0ca0 s9 : 00ffffff8addba50 s10: 0000000000000000 > > [ 11.629678] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000001 > > [ 11.629688] t5 : 0000000000020000 t6 : ffffffffffffffff > > [ 11.629699] status: 0000000000004020 badaddr: 0000000000000000 cause: 000000000000000d > > [ 11.633421] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b > > [ 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] [<ffffffff80005e72>] dump_backtrace+0x1c/0x24 > > [ 11.634162] [<ffffffff809aa9ec>] show_stack+0x2c/0x38 > > [ 11.634274] [<ffffffff809b8482>] dump_stack_lvl+0x60/0x8e > > [ 11.634386] [<ffffffff809b84c4>] dump_stack+0x14/0x1c > > [ 11.634491] [<ffffffff809aaca0>] panic+0x116/0x2e2 > > [ 11.634596] [<ffffffff80015540>] do_exit+0x7ce/0x7d4 > > [ 11.634707] [<ffffffff80015666>] do_group_exit+0x24/0x7c > > [ 11.634817] [<ffffffff80022294>] get_signal+0x7ee/0x830 > > [ 11.634924] [<ffffffff800051c0>] do_notify_resume+0x6c/0x41c > > [ 11.635037] [<ffffffff80003ad4>] 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 > > # 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 Kbuild skeletal support > > > > -- > Best Regards > Guo Ren > > ML: https://lore.kernel.org/linux-csky/
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
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-guoren@kernel.org/
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-guoren@kernel.org/ >
Thx Heiko & Guenter, On Wed, May 25, 2022 at 7:10 PM Heiko Stübner <heiko@sntech.de> 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-guoren@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-guoren@kernel.org/ > > > > > >
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 <heiko@sntech.de> 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-guoren@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-guoren@kernel.org/ > > > > > > > > > > > > > >
On Thu, May 26, 2022 at 3:37 AM Heiko Stübner <heiko@sntech.de> 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 <heiko@sntech.de> 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-guoren@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-guoren@kernel.org/ > > > > > > > > > > > > > > > > > > > > > > > > > >
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 5adcbd9b5e88..6f11df8c189f 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -73,6 +73,7 @@ config RISCV select HAVE_ARCH_KGDB if !XIP_KERNEL select HAVE_ARCH_KGDB_QXFER_PKT select HAVE_ARCH_MMAP_RND_BITS if MMU + select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT select HAVE_ARCH_SECCOMP_FILTER select HAVE_ARCH_TRACEHOOK select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT && MMU @@ -123,12 +124,18 @@ config ARCH_MMAP_RND_BITS_MIN default 18 if 64BIT default 8 +config ARCH_MMAP_RND_COMPAT_BITS_MIN + default 8 + # max bits determined by the following formula: # VA_BITS - PAGE_SHIFT - 3 config ARCH_MMAP_RND_BITS_MAX default 24 if 64BIT # SV39 based default 17 +config ARCH_MMAP_RND_COMPAT_BITS_MAX + default 17 + # set if we run in machine mode, cleared if we run in supervisor mode config RISCV_M_MODE bool @@ -406,6 +413,18 @@ config CRASH_DUMP For more details see Documentation/admin-guide/kdump/kdump.rst +config COMPAT + bool "Kernel support for 32-bit U-mode" + default 64BIT + depends on 64BIT && MMU + help + This option enables support for a 32-bit U-mode running under a 64-bit + kernel at S-mode. riscv32-specific components such as system calls, + the user helper functions (vdso), signal rt_frame functions and the + ptrace interface are handled appropriately by the kernel. + + If you want to execute 32-bit userspace applications, say Y. + endmenu menu "Boot options"