Re: [PATCH 2/3] irq_work: Flush lazy work CPU down on PREEMPT_RT

[Sebastian Andrzej Siewior]

On 2026-09-11 14:55:55 [+0000], sashiko-bot@xxxxxxxxxx wrote:
> [Severity: High]
> Is this statement accurate?
> 
> Several lazy irq_work callbacks (e.g., cgrp_dead_tasks_iwork_fn in
> kernel/cgroup/cgroup.c) rely on this_cpu_*() accessors to process local queues:
> 
> kernel/cgroup/cgroup.c:cgrp_dead_tasks_iwork_fn() {
>     ...
>     lnode = llist_del_all(this_cpu_ptr(&cgrp_dead_tasks));
>     ...
> }
> 
> Executing them remotely on the control CPU causes them to access and drain the
> control CPU's per-CPU lists instead of the dying CPU's. Could this permanently
> leak task structs and pin cgroups on the dead CPU indefinitely, while
> incorrectly altering the state of the control CPU?

The cover letter explained why this shouldn't happen. Additionally the
referenced cgroup patch is already staged for 7.4. 

> > diff --git a/kernel/irq_work.c b/kernel/irq_work.c
> > index 9f19c05c9962c..73eabcbdcd50c 100644
> > --- a/kernel/irq_work.c
> > +++ b/kernel/irq_work.c
> [ ... ]
> > @@ -263,6 +263,17 @@ void irq_work_run(void)
> >  }
> >  EXPORT_SYMBOL_GPL(irq_work_run);
> >  
> > +void irq_work_run_cpu(unsigned int cpu)
> > +{
> > +	if (WARN_ON_ONCE(!cpumask_test_cpu(cpu, cpu_dying_mask)))
> > +		return;
> > +
> > +	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
> > +		return;
> > +
> > +	irq_work_run_list(per_cpu_ptr(&lazy_list, cpu));
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> [Severity: High]
> Could this result in a use-after-free of the irq_work structure?
> 
> irq_work_sync() protects against concurrent execution by waiting for
> IRQ_WORK_BUSY to clear and then calling synchronize_rcu(). This assumes the work
> callback executes inside an RCU read-side critical section.
> 
> However, irq_work_run_cpu() runs from preemptible thread context in
> smpcfd_dead_cpu() without holding the RCU read lock. irq_work_single() can be
> preempted after clearing IRQ_WORK_BUSY but before calling rcuwait_wake_up().
> 
> If irq_work_sync() on another CPU sees the BUSY bit clear, it will call
> synchronize_rcu() which returns immediately, and the caller may then free the
> irq_work structure. When the preempted work function resumes, could it access
> freed memory in rcuwait_wake_up()?

Okay, this is a bummer.

> > +}
> 

Sebastian