On 23-12-23, 14:06, Rex Zhang wrote: > The drain_workqueue() is not in a locked context. In the multi-task case, > it's possible to call queue_work() when drain_workqueue() is ongoing, then > it can cause Call Trace due to pushing a work into a draining workqueue: > Call Trace: > <TASK> > ? __warn+0x7d/0x140 > ? __queue_work+0x2b2/0x440 > ? report_bug+0x1f8/0x200 > ? handle_bug+0x3c/0x70 > ? exc_invalid_op+0x18/0x70 > ? asm_exc_invalid_op+0x1a/0x20 > ? __queue_work+0x2b2/0x440 > queue_work_on+0x28/0x30 > idxd_misc_thread+0x303/0x5a0 [idxd] > ? __schedule+0x369/0xb40 > ? __pfx_irq_thread_fn+0x10/0x10 > ? irq_thread+0xbc/0x1b0 > irq_thread_fn+0x21/0x70 > irq_thread+0x102/0x1b0 > ? preempt_count_add+0x74/0xa0 > ? __pfx_irq_thread_dtor+0x10/0x10 > ? __pfx_irq_thread+0x10/0x10 > kthread+0x103/0x140 > ? __pfx_kthread+0x10/0x10 > ret_from_fork+0x31/0x50 > ? __pfx_kthread+0x10/0x10 > ret_from_fork_asm+0x1b/0x30 > </TASK> > The original lock for event log was spinlock, drain_workqueue() can't > be in a spinlocked context because it may cause task rescheduling. The > spinlock was called in thread and irq thread context, the current usages > does not require a spinlock for event log, so it's feasible to convert > spinlock to mutex. > For putting drain_workqueue() into a locked context, convert the spinlock > to mutex, then lock drain_workqueue() by mutex. This fails to apply for me, pls rebase -- ~Vinod
