On Fri, Oct 2, 2020 at 8:27 AM Johannes Berg johannes@sipsolutions.net wrote:
On Thu, 2020-10-01 at 21:31 -0700, syzbot wrote:
syzbot has bisected this issue to:
commit 16d4d43595b4780daac8fcea6d042689124cb094 Author: Christoph Hellwig hch@lst.de Date: Wed Jul 20 01:38:55 2016 +0000
xfs: split direct I/O and DAX pathLOL!
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