Re: [PATCH] cgroup/cpuset: Handle cpu hotplug race in guarantee_active_cpus()

[Farhad Alemi]

Apologies for the delay in response. Upon our run, the patched kernel
388b607d107c07aaade04c7f22f344cab6bdccd3 no longer panics when facing
the attached reproducer.

Thanks!

On Mon, Aug 31, 2026 at 5:09 PM Waiman Long <longman@xxxxxxxxxx> wrote:
>
> On 8/30/26 9:50 PM, Ridong Chen wrote:
> >
> >
> > On 8/29/2026 2:03 AM, Waiman Long wrote:
> >> With commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug
> >> processing synchronous"), the cpuset hotplug operation becomes
> >> synchronous. That commit also removes the code that handles the race
> >> between cpuset_hotplug_work and cpu hotplug notifier with the assumption
> >> that race is now gone. Later commit 7a0aabd9ce69 ("cgroup/cpuset:
> >> Always use cpu_active_mask") updates the cpuset code to always use
> >> cpu_active_mask instead of cpu_ohline_mask in various places including
> >> guarantee_online_cpus() which is also renamed to guarantee_active_cpus()
> >> in that commit.
> >>
> >> In the case of CPU offline operation, cpuset_active_mask is updated
> >> first in sched_cpu_deactivate() to remove the offline CPU before
> >> cpuset_handle_hotplug() is called to update the effective_cpus of the
> >> affected cpusets. The cpu_online_mask is updated after that near the end
> >> of the offline operation to remove the offline CPU. As a result, the
> >> race
> >> comes back and the top cpuset may not have any active CPU leading to
> >> NULL
> >> pointer dereference during the race window when guarantee_active_cpus()
> >> is called after cpu_active_mask is updated to remove the CPU to be torn
> >> down but before cpuset_handle_hotplug() is able to properly update the
> >> effective_cpus of the top cpuset.
> >>
> >
> > Hi Longman,
> >
> > Thank you for the patch. I believe it should resolve the issue.
> > Could Farhad please verify whether it works as expected?
> >
> >> Fix this by adding back the NULL cs check to avoid this problem.
> >> However,
> >> the output of guarantee_active_cpus() will be unreliable during that
> >> race window.
> >>
> >
> > If guarantee_active_cpus() can return unreliable results during that
> > race window, should it instead return an error when it cannot
> > guarantee that the active CPUs are usable? Otherwise, callers might
> > use an incorrect 'pmask', which could lead to other issues downstream.
>
> I am thinking about that too. However, the change will be more extensive
> and it is that easy to figure out if we are the in the race window. So
> more thought will be needed before we can make that change. In the mean
> time, we have to fix the NULL pointer dereference and it has behaved
> like that before.
>
> Cheers,
> Longman
>

Attachment: reproducer.c
Description: Binary data