On Fri, Aug 28, 2020 at 04:38:25PM +0100, Al Viro wrote: > On Fri, Aug 28, 2020 at 06:18:17AM -0700, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: d012a719 Linux 5.9-rc2 > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=15aa650e900000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=891ca5711a9f1650 > > dashboard link: https://syzkaller.appspot.com/bug?extid=c92c93d1f1aaaacdb9db > > compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12ecb939900000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=140a19a9900000 > > Trying to reproduce... OK, I think I see what's going on. ep_loop_check_proc() runs into an already doomed file that has already committed to getting killed (->f_count is already at 0), but still hadn't gotten through its epitems removal (e.g. has its eventpoll_release_file() sitting there trying to get epmutex). Blindly bumping refcount here is worse than useless. Try this, to verify that this is what's going on; it's _not_ a proper fix, but it should at least tell if we have something else going on. diff --git a/fs/eventpoll.c b/fs/eventpoll.c index e0decff22ae2..4590223b2de9 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1995,7 +1995,7 @@ static int ep_loop_check_proc(void *priv, void *cookie, int call_nests) * during ep_insert(). */ if (list_empty(&epi->ffd.file->f_tfile_llink)) { - get_file(epi->ffd.file); + if (get_file_rcu(epi->ffd.file)) list_add(&epi->ffd.file->f_tfile_llink, &tfile_check_list); }
