Hello, On Fri, Aug 22, 2025 at 02:00:10AM +0800, Julian Sun wrote: ... > Do you mean logic like this? > > for (i = 0; i < MEMCG_CGWB_FRN_CNT; i++) > wb_wait_for_completion(&memcg->cgwb_frn[i].done); > kfree(memcg); > > But there still exist task hang issues as long as > wb_wait_for_completion() exists. Ah, right. I was just thinking about the workqueue being stalled. The problem is that the wait itself is too long. > I think the scope of impact of the current changes should be > manageable. I have checked all the other places where wb_queue_work() > is called, and their free_done values are all 0, and I also tested > this patch with the reproducer in [1] with kasan and kmemleak enabled. > The test result looks fine, so this should not have a significant > impact. > What do you think? My source of reluctance is that it's a peculiar situation where flushing of a cgroup takes that long due to hard throttling and the self-freeing mechanism isn't the prettiest thing. Do you think you can do the same thing through custom waitq wakeup function? Thanks. -- tejun
