Hello Zhaoyang, On Tue, Feb 18, 2025 at 10:49:04AM +0800, Zhaoyang Huang wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: c674aa7c289e Add linux-next specific files for 20250212 > > git tree: linux-next > > console+strace: https://syzkaller.appspot.com/x/log.txt?x=125063f8580000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=a0fd539126ae5541 > > dashboard link: https://syzkaller.appspot.com/bug?extid=c104904eeb2c0edbdb06 > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=158a3bdf980000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17e18aa4580000 > #syz test > > diff --git a/drivers/block/loop.c b/drivers/block/loop.c > index 68c943a77e41..354d77f9228b 100644 > --- a/drivers/block/loop.c > +++ b/drivers/block/loop.c > @@ -1972,7 +1972,8 @@ static void loop_process_work(struct loop_worker *worker, > * *and* the worker will not run again which ensures that it > * is safe to free any worker on the idle list > */ > - if (worker && !work_pending(&worker->work)) { > + if (worker && !work_pending(&worker->work) > + && list_empty(&worker->idle_list)) { > worker->last_ran_at = jiffies; > list_add_tail(&worker->idle_list, &lo->idle_worker_list); > loop_set_timer(lo); The `work` to be queued may originate from RB tree or lo->rootcg_work, so it may be freed during queuing without the lock. I think you may need to revert the patch. Thanks, Ming
