On Wed, Jan 30, 2019 at 3:30 PM Dmitry Vyukov <dvyu...@google.com> wrote: > > On Wed, Jan 30, 2019 at 3:20 PM Florian Westphal <f...@strlen.de> wrote: > > > > Dmitry Vyukov <dvyu...@google.com> wrote: > > > > syzbot <syzbot+e6e1fe9148cffa18c...@syzkaller.appspotmail.com> wrote: > > > > > Hello, > > > > > > > > > > syzbot found the following crash on: > > > > > > > > > > HEAD commit: 085c4c7dd2b6 net: lmc: remove -I. header search path > > > > > git tree: net-next > > > > > console output: > > > > > https://syzkaller.appspot.com/x/log.txt?x=12347128c00000 > > > > > kernel config: > > > > > https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68 > > > > > dashboard link: > > > > > https://syzkaller.appspot.com/bug?extid=e6e1fe9148cffa18cf97 > > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > > > > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > > > > > net-next doesn't contain the fixes for the rbtree fallout yet, so > > > > this might already be fixed (fingers crossed). > > > > > > Hi Florian, > > > > > > What is that fix for the record? > > > > I don't know. I managed to add every bug class imagineable in that series > > 8-( > > > > The last (most recent) fix from the 'fallout cleanup' is: > > 12750abad517a991c4568969bc748db302ab52cd > > ("xfrm: policy: fix infinite loop when merging src-nodes") > > > > so if syzkaller can generate a splat with that change present > > something is still broken. > > > > > We will need to close this later. Or perhaps we can already mark this > > > as fixed by that patch with "#syz fix:" command? > > > > There are a lot of open xfrm related splats that could all be explained > > by the rbtree bugs (one had a reproducer, the fix has appropriate > > reported-by tag). > > > > It would be great if there was a way to tell syzkaller to report those > > again if they still appear. > > That's exactly what "#syz fix:" will do. > syzbot will wait until the fixing commit appears in all builds/trees > it tests, then close this bug, and then any new similarly looking > crash will produce a new bug report. So if the patch indeed fixes the > bug, then the bug will be closed and we are done. If it does not fix > this bug, then we will get another report but at that time on a tree > that includes the commit. > > > I could pretend and claim above commit as "sys-fix", but it seems fishy. > > > > Let me know and I can tag all of them. > > It's "safe" to mark these crashes as fixed when we are not 100% sure > in the sense that we won't lose the bug (it will be reported again > later if it's not fixed). > It's also useful to keep the list of open/active bugs shorter and more > precise (don't leave too many obsoleted open bugs). What happened > multiple times is that a bug was fixed but left open, and then a > similarly looking crashes started happening again (a new bug), but it > wasn't reported by syzbot because for syzbot it looked like the old > still unfixed bug.
Thanks for cleaning it all up! (Florian updated 17 other bugs)
