Re: [PATCH v7 11/12] virt/steal_monitor: Act on steal time periodically and decide on preferred CPUs

[Yury Norov]

On Mon, Jul 13, 2026 at 11:18:59AM +0530, Shrikanth Hegde wrote:

... 

> > > +requeue_work:
> > > +	/* maintain design constructs always */
> > > +	WARN_ON_ONCE(cpumask_empty(cpu_preferred_mask));
> > > +	WARN_ON_ONCE(!cpumask_subset(cpu_preferred_mask, cpu_active_mask));
> > 
> > cpu_read_lock here? And again, you should do something to restore
> > integrity. WARN_ON is not enough. The simplest and safest thing you
> > can do is to unload the driver. You definitely shouldn't schedule a
> > new work against the broken cpu_preferred_mask.
> 
> How about not requeue the work if it broken. Add a pr_err and return.
> That makes driver pretty much nop until rmmod.
> 
>         /* maintain design constructs always */
>         if (cpumask_empty(cpu_preferred_mask)) {
>                 pr_err("empty cpu_preferred_mask, stop steal_monitor work");
>                 return;
>         }
> 
>         if (!cpumask_subset(cpu_preferred_mask, cpu_active_mask)) {
>                 pr_err("preferred: %*pbl is not a subset of active: %*pbl, stop steal_monitor work\n",
>                        pr_cpuamsk_args(cpu_preferred_mask), pr_cpuamsk_args(cpu_active_mask));
> 		return;
> 	}
 
That would keep broken preferred cpumask working in the kernel.

Imagine, it becomes empty on Friday night. That severely hurts 
the scheduling on the VMs. So, your approach requires the VM
admin to come and manually rmmod the driver. This is not how
he wanted to spend the evening, I guess. :)

So, ether unload the driver, or actively recover the invariant.

Thanks,
Yury