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

[Shrikanth Hegde]

Hi Yury.

On 7/14/26 6:01 PM, Yury Norov wrote:
> 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.

yes, i will restore it to the active mask and not requeue the work
and add a pr_err.

>

Can we unload the driver after init completes?

This is happening in work function after module is loaded.
This invariant maybe broken after a few days driver was loaded.

> Thanks,
> Yury