On Fri, Oct 2, 2020 at 8:27 AM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Thu, 2020-10-01 at 21:31 -0700, syzbot wrote: > > syzbot has bisected this issue to: > > > > commit 16d4d43595b4780daac8fcea6d042689124cb094 > > Author: Christoph Hellwig <hch@xxxxxx> > > Date: Wed Jul 20 01:38:55 2016 +0000 > > > > xfs: split direct I/O and DAX path > > > > LOL! > > Unlike in many other cases, here I don't even see why it went down that > path. You'd think that Christoph's commit should have no effect > whatsoever, but here we are with syzbot claiming a difference? > > I mean, often enough it says something is "caused" by a patch because > that caused e.g. generic netlink family renumbering, or because it > emitted some other ioctl() calls or whatnot that are invalid before and > valid after some other (feature) patch (or vice versa sometimes), but > you'd think that this patch would have _zero_ userspace observable > effect? > > Which I guess means that the reproduction of this bug is random, perhaps > timing related. Hi Johannes, syzbot provides bisection log which usually answers the why question. In this case bisection was diverged by an unrelated kernel bug. That's the most common reason for wrong bisection results. If you are interested in more reasons for wrong bisection results, some time ago I did a large analysis of bisection results: https://groups.google.com/g/syzkaller/c/sR8aAXaWEF4/m/tTWYRgvmAwAJ
