Re: BUG: corrupted list in __dentry_kill (2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux