Re: [PATCH v2] cpufreq: schedutil: Serialize start against rate limit updates

From: Hui Su

Date: Mon Oct 12 2026 - 21:49:54 EST


> But instead, I'd add a wrapper around sugov_update_rate_limit_us() that would do
>
> guard(mutex)(&sg_policy->tunables->attr_set->update_lock);
>
> before calling it and I'd invoke that wrapper from here.
>
> Also, the comment should explain why the locking is needed which it
> doesn't do now.

Agreed. I removed the generic gov_attr_set lock helpers and added a
schedutil-local wrapper using guard(mutex) around the raw update helper.

The comment now explains how an unsynchronized start can overwrite the
cached delay with a value derived from a stale rate_limit_us value.
rate_limit_us_store() continues to call the raw helper while holding
update_lock.

I'll send v3 separately.

Thanks,
Hui