On Mon, Mar 15, 2021 at 5:55 PM Ben Dooks <ben.do...@codethink.co.uk> wrote: > > On Fri, Mar 12, 2021 at 9:12 PM Ben Dooks <ben.do...@codethink.co.uk> wrote: > > >>> Still no luck for the moment, can't reproduce it locally, my test is > >>> maybe not that good (I created threads all day long in order to trigger > >>> the put_user of schedule_tail). > >> > >> It may of course depend on memory and other stuff. I did try to see if > >> it was possible to clone() with the child_tid address being a valid but > >> not mapped page... > >> > >>> Given that the path you mention works most of the time, and that the > >>> status register in the stack trace shows the SUM bit is not set whereas > >>> it is set in put_user, I'm leaning toward some race condition (maybe an > >>> interrupt that arrives at the "wrong" time) or a qemu issue as you > >>> mentioned. > >> > >> I suppose this is possible. From what I read it should get to the > >> point of being there with the SUM flag cleared, so either something > >> went wrong in trying to fix the instruction up or there's some other > >> error we're missing. > >> > >>> To eliminate qemu issues, do you have access to some HW ? Or to > >>> different qemu versions ? > >> > >> I do have access to a Microchip Polarfire board. I just need the > >> instructions on how to setup the test-code to make it work on the > >> hardware. > > > > For full syzkaller support, it would need to know how to reboot these > > boards and get access to the console. > > syzkaller has a stop-gap VM backend which just uses ssh to a physical > > machine and expects the kernel to reboot on its own after any crashes. > > > > But I actually managed to reproduce it in an even simpler setup. > > Assuming you have Go 1.15 and riscv64 cross-compiler gcc installed > > > > $ go get -u -d github.com/google/syzkaller/... > > $ cd $GOPATH/src/github.com/google/syzkaller > > $ make stress executor TARGETARCH=riscv64 > > $ scp bin/linux_riscv64/syz-execprog bin/linux_riscv64/syz-executor > > your_machine:/ > > > > Then run ./syz-stress on the machine. > > On the first run it crashed it with some other bug, on the second run > > I got the crash in schedule_tail. > > With qemu tcg I also added -slowdown=10 flag to syz-stress to scale > > all timeouts, if native execution is faster, then you don't need it. > > I have built the tools and got it to start. > > It would be helpful for the dashboard to give the qemu version and > how it was launched (memory, cpus etc)
Hi Ben, syzbot will show info about qemu version/args in "VM info" column then this commit is deployed (should happen by tomorrow); https://github.com/google/syzkaller/commit/4a3131941837f1fab321bcdfcac13ac4fb480684
