On Thu, Dec 12, 2019 at 2:38 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Dec 12, 2019 at 07:48:14AM +0100, Dmitry Vyukov wrote: > > On Thu, Dec 12, 2019 at 7:12 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Wed, Dec 11, 2019 at 09:59:11PM -0800, syzbot wrote: > > > > Hello, > > > > > > > > syzbot found the following crash on: > > > > > > > > HEAD commit: 938f49c8 Add linux-next specific files for 20191211 > > > > git tree: linux-next > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=150eba1ee00000 > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=96834c884ba7bb81 > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=31043da7725b6ec210f1 > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12dc83dae00000 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16ac8396e00000 > > > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > > Reported-by: syzbot+31043da7725b6ec210f1@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > Already fixed in a3d1e7eb5abe3aa1095bc75d1a6760d3809bd672 > > > > This commit was in the tested tree already as far as I can see. > > Broken version (653f0d05be0948e7610bb786e6570bb6c48a4e75) is there, its > fixed replacement (a3d1e7eb5abe3aa1095bc75d1a6760d3809bd672) is not. Right, sorry, I looked only at the title when checked if it's in the tree or not. > Look, I realize that your setup is oriented to "followup commit Y fixes > a bug in earlier commit X", and sometimes it's the only possibility > (when X has already been in mainline), but in general it's spelled > "bisection hazard for no damn reason". Fixes are folded in. > Routinely. What's more, in this case the fixed version had been done > (and pushed out) before syzbot has seen the original, so putting > any metadata into commit message hadn't been an option. > > If there is some format understandable for syzbot for such cases > ("bug is caused by commit X; Y is a replacement that should not > exhibit the same bug, so if you see that behaviour on a tree > that doesn't contain X, report it. X-containing trees ought > to go extinct reasonably soon"), please tell what it is. > Otherwise this situation will keep repeating - I am not going > to stop folding fixes into developing patches. I did not find anything that could serve as these X/Y here. Commit hashes in linux-next are pointless and won't match against other trees. Commit titles seem to be the best bet for kernel, but this is exactly the case where they fall short. But in this case I think we can safely mark this as: #syz fix: simple_recursive_removal(): kernel-side rm -rf for ramfs-style filesystems This should work because syzbot does coarser-grained check than "if you see that behaviour on a tree that doesn't contain X". Instead it will wait until _all_ tested trees will have X and only then close the bug and report it again if it sees it again. Since the commit is already fixed in linux-next, when all trees including mainline and bpf/bpf-next will get it, it should be the fixed version. > Speaking of bisect hazards, I'd recommend to check how your bisect > went - the bug is definitely local to this commit and I really > wonder what had caused the bisect to go wrong in this particular > case. I did not get the relation of folding to bisection. Or you mean these are just separate things? In this particular case the reason seems to be the same as for most kernel bisections -- too many unrelated bugs layering one onto another. If you are interested in more details about why kernel bisection go wrong in general, I've published a bunch of info here (including detailed stats on reason): https://groups.google.com/g/syzkaller/c/sR8aAXaWEF4/m/tTWYRgvmAwAJ https://github.com/google/syzkaller/issues/1051 https://docs.google.com/spreadsheets/d/1WdBAN54-csaZpD3LgmTcIMR7NDFuQoOZZqPZ-CUqQgA/edit#gid=0
