On 07.05.2025 16:37, Ross Lagerwall wrote:
> On Thu, Apr 17, 2025 at 2:23 PM Jan Beulich <jbeul...@suse.com> wrote:
>>
>> On 17.04.2025 12:30, Ross Lagerwall wrote:
>>> --- a/xen/drivers/acpi/pmstat.c
>>> +++ b/xen/drivers/acpi/pmstat.c
>>> @@ -104,6 +104,14 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
>>> cpufreq_residency_update(op->cpuid, pxpt->u.cur);
>>>
>>> ct = pmpt->perf.state_count;
>>> +
>>> + if ( op->u.getpx.total < ct )
>>> + {
>>> + spin_unlock(cpufreq_statistic_lock);
>>> + ret = -ENOSPC;
>>> + break;
>>> + }
>>
>> Simply producing an error is not an option imo. See pmstat_get_cx_stat()'s
>> behavior. Imo the calculation of ct wants to become
>>
>> ct = min(pmpt->perf.state_count, op->u.getpx.total);
>>
>> yet then the copying of the 2-dim array of data becomes more complicated
>> when ct < pmpt->perf.state_count. An option may be to document that this
>> array is copied only when the buffer is large enough.
>
> Another option would be for the caller to explicitly pass in both array sizes
> and Xen can copy as much as fits since in either case there would need to be a
> way for Xen to return how much it has (separately) copied for both arrays.
> Does
> that make sense?
May be an option, but would require adjustments to the interface itself.
Jan
