On Mon, Oct 04, 2021 at 10:15:16AM -0300, Jason Gunthorpe wrote: > On Mon, Oct 04, 2021 at 02:42:11PM +0200, Dmitry Vyukov wrote: > > On Mon, 4 Oct 2021 at 12:45, syzbot > > <syzbot+3a992c9e4fd9f0e6fd0e@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: c7b4d0e56a1d Add linux-next specific files for 20210930 > > > git tree: linux-next > > > console output: https://syzkaller.appspot.com/x/log.txt?x=104be6cb300000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=c9a1f6685aeb48bd > > > dashboard link: https://syzkaller.appspot.com/bug?extid=3a992c9e4fd9f0e6fd0e > > > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+3a992c9e4fd9f0e6fd0e@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > +RESTRACK maintainers > > > > (it would also be good if RESTRACK would print a more standard oops > > with stack/filenames, so that testing systems can attribute issues to > > files/maintainers). > > restrack certainly should trigger a WARN_ON to stop the kernel.. But I > don't know what stack track would be useful here. The culprit is > always the underlying driver, not the core code.. We had WARN_ON() in early versions, but it didn't give us anything except spammed dmesg, so I changed it to more lighter version. > > Anyhow, this report is either rxe or rds by the look of it. > > Jason
