Messages in this thread | | | From | Dmitry Vyukov <> | Date | Sat, 28 May 2022 10:26:44 +0200 | Subject | Re: [syzbot] riscv/fixes test error: lost connection to test machine |
| |
On Sat, 28 May 2022 at 10:03, Alexandre Ghiti <alex@ghiti.fr> wrote: > >>>>>> Hello, > >>>>>> > >>>>>> syzbot found the following issue on: > >>>>>> > >>>>>> HEAD commit: c932edeaf6d6 riscv: dts: microchip: fix gpio1 reg property.. > >>>>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > >>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1418add5f00000 > >>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=aa6b5702bdf14a17 > >>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=2c5da6a0a16a0c4f34aa > >>>>>> compiler: riscv64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > >>>>>> userspace arch: riscv64 > >>>>>> > >>>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit: > >>>>>> Reported-by: syzbot+2c5da6...@syzkaller.appspotmail.com > >>>>> The CONFIG_KASAN_VMALLOC allows riscv kernel to boot, but now Go > >>>>> processes started crashing with: > >>>>> > >>>>> 1970/01/01 00:06:55 fuzzer started > >>>>> runtime: lfstack.push invalid packing: node=0xffffff5908a940 cnt=0x1 > >>>>> packed=0xffff5908a9400001 -> node=0xffff5908a940 > >>>>> fatal error: lfstack.push > >>>>> runtime stack: > >>>>> runtime.throw({0x30884c, 0xc}) > >>>>> /usr/local/go/src/runtime/panic.go:1198 +0x60 > >>>>> runtime.(*lfstack).push(0xdb3850, 0xffffff5908a940) > >>>>> /usr/local/go/src/runtime/lfstack.go:30 +0x1a8 > >>>>> > >>>>> Go runtime tries to shove some data into the upper 16 bits of pointers > >>>>> assuming they are unused. > >>>>> However, the original pointer node=0xffffff5908a940 suggest riscv now > >>>>> has 56-bit users-space address space? > >>>> > >>>> Yes, sv57 was merged recently. > >>>> > >>>>> Documentation/riscv/vm-layout.rst claims 48-bit pointers: > >>>>> " > >>>>> The RISC-V privileged architecture document states that the 64bit addresses > >>>>> "must have bits 63–48 all equal to bit 47, or else a page-fault exception will > >>>>> occur.": > >>>> > >>>> Thanks for pointing that, I extracted that from the specification before sv57 was specified, I'll fix that. > >>>> > >>>> The current kernel code will use sv57 as it is supported and advertised by qemu, and to my knowledge, you can't downgrade to sv48 unless by re-compiling qemu using the following: > >>>> > >>>> diff --git a/target/riscv/csr.c b/target/riscv/csr.c > >>>> index 6dbe9b541f..a64b50ed75 100644 > >>>> --- a/target/riscv/csr.c > >>>> +++ b/target/riscv/csr.c > >>>> @@ -637,7 +637,7 @@ static const char valid_vm_1_10_64[16] = { > >>>> [VM_1_10_MBARE] = 1, > >>>> [VM_1_10_SV39] = 1, > >>>> [VM_1_10_SV48] = 1, > >>>> - [VM_1_10_SV57] = 1 > >>>> + [VM_1_10_SV57] = 0 > >>>> }; > >>>> > >>>> /* Machine Information Registers */ > >>>> > >>>>> ... > >>>>> 0000000000000000 | 0 | 0000003fffffffff | 256 GB | > >>>>> user-space virtual memory, different per mm > >>>>> " > >>> There is no kernel config to force SV48/39, right? > >> > >> No, we rely on what the hardware advertises, if it supports sv57, we'll go for sv57, if not, we'll try sv48...etc. I had some patches to force the downgrade by using the device tree but they never got merged though. > > +original CC list > > > > FTR sent Go runtime change to support SV57: > > https://go-review.googlesource.com/c/go/+/409055 > > > Thank you for that, I'll pull that into Ubuntu when merged. Do you know > if any other programming language does the same and would need a fix too?
Nothing comes to mind right now. But this is not only about language runtimes, it's about all software out there. However, x86 has 5-level pages now as well, it should stomp on these problems earlier... but somehow it did not happen for Go runtime.
| |