Re: [PATCH] sched: flush plug in schedule_preempt_disabled() to prevent deadlock

[Tejun Heo <tj@kernel.org>]

Hello, Ming.

On Tue, May 12, 2026 at 11:45:14PM +0800, Ming Lei wrote:
> On Tue, May 12, 2026 at 02:40:21PM +0200, Peter Zijlstra wrote:
> > On Tue, May 12, 2026 at 02:04:32PM +0200, Peter Zijlstra wrote:
> > > On Tue, May 12, 2026 at 04:59:39PM +0800, Ming Lei wrote:
> > > > On preemptible kernels, a deadlock can occur when a task with plugged IO
> > > > calls schedule_preempt_disabled():
> > > > 
> > > >   schedule_preempt_disabled()
> > > >     sched_preempt_enable_no_resched()  // preemption now enabled
> > > >     schedule()                         // <-- preemption can happen here
> > > >       sched_submit_work()
> > > >         blk_flush_plug()
> > > > 
> > > > After sched_preempt_enable_no_resched() re-enables preemption, the task
> > > > can be preempted (e.g., by a higher-priority RT task) before reaching
> > > > blk_flush_plug() in sched_submit_work(). Since the task's state is
> > > > already TASK_UNINTERRUPTIBLE (set by the mutex/rwsem slowpath caller),
> > > > requests in current->plug remain unflushed for an unbounded time.
> > > > 
> > > > If another task depends on those plugged requests to make progress (e.g.,
> > > > to release a lock the sleeping task needs), a deadlock results:
> > > > 
> > > >   - Task A (writeback worker): holds plugged IO, preempted before
> > > >     flushing, stuck on run queue behind higher-priority work
> > > >   - Task B: waiting for IO completion from Task A's plug, holds a lock
> > > >     that Task A needs to be woken up

My memory is hazy around io_schedule but the above reads really weird to me.
A task, regardless of its current state stays on the runqueue when
preempted, so the condition is temporary. As soon as the preempted task can
get CPU, it should unwind the situation. That's not a deadlock. Is the
problem that there can be preemption-induced delay in flushing the plugs?

Thanks.

-- 
tejun