On Wed, Oct 3, 2018 at 1:21 AM, Shuah Khan <shuah@xxxxxxxxxx> wrote: > On 10/02/2018 10:42 AM, Dmitry Vyukov wrote: >> On Tue, Oct 2, 2018 at 6:04 PM, Shuah Khan <shuah@xxxxxxxxxx> wrote: >>> On 09/04/2018 12:52 PM, syzbot wrote: >>>> Hello, >>>> >>>> syzbot found the following crash on: >>>> >>>> HEAD commit: 420f51f4ab6b Merge tag 'arm64-fixes' of git://git.kernel.o.. >>>> git tree: upstream >>>> console output: https://syzkaller.appspot.com/x/log.txt?x=126a6f0e400000 >>>> kernel config: https://syzkaller.appspot.com/x/.config?x=531a917630d2a492 >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bccc1fe10b70fadc78d0 >>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental) >>>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=121caa46400000 >>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000 >>> >>> C producer doesn't reproduce the problem on 4.19-rc5. Does this C producer >>> depend on state of the machine? i.e what is the status of vhci_hcd - are >>> there any devices attached? >> >> Hi Shuah, >> >> syzbot always runs tests reproducers on a clean machine. There is some >> state are running a Debian wheezy init, but no test/fuzz/stress >> workload is run before the reproducer. >> syzbot also uses VMs, so there are no real devices attached. And it's >> GCE VMs (not qemu), and I think GCE does not even emulate any USB >> devices. >> >> An obvious thing to try would be to use the exact commit and config >> syzbot gave (rather than 4.19-rc5). >> You can also take the image syzbot uses here: >> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce >> >> >>> I can see the problem looking at the code and fix is easy. However, I would >>> like be able to reproduce it and verify the fix works. Also this would be a >>> good regression for the driver I could consider adding to selftests. >> >> syzbot can test fixes for bugs with reproducers: >> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#testing-patches >> So it can test your fix. But this obviously won't help with a test. >> > > Tried the same config and no luck. Any chance you have the complete dmesg? By "complete" you mean "from the boot"? If yes, then no, we don't keep it, full output can be huge and it's not a moving part. I've captured boot output from another similar machine, unfortunately dmesg buffer is not large enough to fit it all, so not sure if you will find what you are looking for there: https://gist.githubusercontent.com/dvyukov/11b83aeda0466a0f171451d86ab36e15/raw/57121db6cf1bbb5e57c08746241b03904bde95f6/gistfile1.txt
