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 path
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14f662b7900000 start commit: 87d5034d Merge tag 'mlx5-updates-2020-09-30' of git://git... git tree: net-next final oops: https://syzkaller.appspot.com/x/report.txt?x=16f662b7900000 console output: https://syzkaller.appspot.com/x/log.txt?x=12f662b7900000 kernel config: https://syzkaller.appspot.com/x/.config?x=7b5cc8ec2218e99d dashboard link: https://syzkaller.appspot.com/bug?extid=5f9392825de654244975 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1100d333900000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1414c997900000
Reported-by: syzbot+5f9392825de654244975@syzkaller.appspotmail.com Fixes: 16d4d43595b4 ("xfs: split direct I/O and DAX path")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
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 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.
johannes
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
b.a.t.m.a.n@lists.open-mesh.org
-
Dmitry Vyukov -
Johannes Berg -
syzbot