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

[Shrikanth Hegde <sshegde@linux.ibm.com>]

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