kernel/drivers/cpufreq/cpufreq_stats.c, branch 0x221E-v0.0.1-v6.19

cpufreq: stats: Fix buffer overflow detection in trans_stats()

2023-10-24T20:02:06Z

Commit 3c0897c180c6 ("cpufreq: Use scnprintf() for avoiding potential buffer overflow") switched from snprintf to the more secure scnprintf but never updated the exit condition for PAGE_SIZE. As the commit say and as scnprintf document, what scnprintf returns what is actually written not counting the '\0' end char. This results in the case of len exceeding the size, len set to PAGE_SIZE - 1, as it can be written at max PAGE_SIZE - 1 (as '\0' is not counted) Because of len is never set to PAGE_SIZE, the function never break early, never prints the warning and never return -EFBIG. Fix this by changing the condition to PAGE_SIZE - 1 to correctly trigger the error. Cc: 5.10+ # 5.10+ Fixes: 3c0897c180c6 ("cpufreq: Use scnprintf() for avoiding potential buffer overflow") Signed-off-by: Christian Marangi [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki

cpufreq: stats: Improve the performance of cpufreq_stats_create_table()

2023-08-21T18:57:30Z

In the worst case, the freq_table of policy data is not sorted and contains duplicate frequencies, this means that it needs to iterate through the entire freq_table of policy to ensure each frequency is unique in the freq_table of stats data, this has a time complexity of O(N^2), where N is the number of frequencies in the freq_table of policy. However, if the policy.freq_table is already sorted and contains no duplicate frequencies, it can reduce the time complexity of creating stats.freq_table to O(N), the 'freq_table_sorted' field of policy data can be used to indicate whether the policy.freq_table is sorted. Signed-off-by: Liao Chang Acked-by: Viresh Kumar Reviewed-by: Dhruva Gole [ rjw: Fix typo in changelog, remove redundant parens ] Signed-off-by: Rafael J. Wysocki

cpufreq: stats: Convert to use sysfs_emit_at() API

2022-12-06T11:20:07Z

Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by: ye xingchen Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: Clean up local variable in cpufreq_stats_create_table()

2021-06-07T11:47:57Z

Local variable 'count' will be initialized and 'ret' is also not required, so remove the redundant initialization and get rid of 'ret'. Signed-off-by: Shaokun Zhang Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: Use local_clock() instead of jiffies

2020-12-11T18:53:58Z

local_clock() has better precision and accuracy as compared to jiffies, lets use it for time management in cpufreq stats. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: Fix string format specifier mismatch

2020-10-12T10:32:10Z

Fix following warning: drivers/cpufreq/cpufreq_stats.c:63:10: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int' Fixes: 40c3bd4cfa6f ("cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()") Reported-by: kernel test robot Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: Add memory barrier to store_reset()

2020-10-07T15:13:15Z

There is nothing to prevent the CPU or the compiler from reordering the writes to stats->reset_time and stats->reset_pending in store_reset(), in which case the readers of stats->reset_time may see a stale value. Moreover, on 32-bit arches the write to reset_time cannot be completed in one go, so the readers of it may see a partially updated value in that case. To prevent that from happening, add a write memory barrier between the writes to stats->reset_time and stats->reset_pending in store_reset() and corresponding read memory barrier in the readers of stats->reset_time. Fixes: 40c3bd4cfa6f ("cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()") Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar

cpufreq: stats: Enable stats for fast-switch as well

2020-10-05T13:13:43Z

Now that all the blockers are gone for enabling stats in fast-switching case, enable it. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: Mark few conditionals with unlikely()

2020-10-05T13:13:43Z

Since this will be part of the scheduler's hotpath in some cases, use unlikely() for few of the obvious conditionals. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: stats: Remove locking

2020-10-05T13:13:43Z

The locking isn't required anymore as stats can get updated only from one place at a time. Remove it. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki