On 07/06/2020 15:37, Xiaoguang Wang wrote: >>> The reason is that once io_sq_thread has a valid mm, schedule subsystem >>> may call task_tick_numa() adding a task_numa_work() callback, which will >>> visit mm, then above panic will happen. >>> >>> To fix this bug, only call task_work_run() before dropping mm. >> >> So, the problem is that poll/async paths re-issue requests with >> __io_queue_sqe(), which doesn't care about current->mm, and which >> can be NULL for io_sq_thread(). Right? > No, above panic is not triggered by poll/async paths. > See below code path: > ==> task_tick_fair() > ====> task_tick_numa() > ======> task_work_add, work is task_numa_work, which will visit mm. > > In sqpoll mode, there maybe are sqes that need mm, then above codes > maybe executed by schedule subsystem. In io_sq_thread, we drop mm before > task_work_run, if there is a task_numa_work, panic occurs. > Got it, thanks for explaining -- Pavel Begunkov
