From: Kaushlendra Kumar kaushlendra.kumar@intel.com
[ Upstream commit 57b100d4cf14276e0340eecb561005c07c129eb8 ]
The cpupower_write_sysfs() function currently returns -1 on write failure, but the function signature indicates it should return an unsigned int. Returning -1 from an unsigned function results in a large positive value rather than indicating an error condition.
Fix this by returning 0 on failure, which is more appropriate for an unsigned return type and maintains consistency with typical success/failure semantics where 0 indicates failure and non-zero indicates success (bytes written).
Link: https://lore.kernel.org/r/20250828063000.803229-1-kaushlendra.kumar@intel.co... Signed-off-by: Kaushlendra Kumar kaushlendra.kumar@intel.com Signed-off-by: Shuah Khan skhan@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES
**What It Fixes** - Corrects an unsigned return error path in `cpupower_write_sysfs()`: changes `return -1;` to `return 0;` inside the failure branch `if (numwritten < 1)` in `tools/power/cpupower/lib/cpupower.c:56-60`. This prevents `-1` from wrapping to a large unsigned value that looks like success. - Aligns write semantics with read: `cpupower_read_sysfs()` already returns `0` on failure (`tools/power/cpupower/lib/cpupower.c:30-38`), and `cpupower_write_sysfs()` already returns `0` when `open()` fails (`tools/power/cpupower/lib/cpupower.c:51-53`).
**User-Visible Impact** - Current callers interpret `<= 0` as failure. With the buggy `-1` (wrapped to large unsigned), failures are silently treated as success. Examples: - `tools/power/cpupower/utils/helpers/misc.c:83` - `tools/power/cpupower/utils/helpers/misc.c:102` - `tools/power/cpupower/utils/helpers/misc.c:120` - `tools/power/cpupower/utils/helpers/misc.c:289` - After this fix, these checks correctly detect write failures (permission denied, invalid sysfs paths, etc.), improving reliability of cpupower operations like setting EPP, turbo boost, or perf bias.
**Scope and Risk** - One-line change; no API/signature change; no architectural changes. - Confined to `tools/` (cpupower userspace library). No kernel subsystem touched. - Behavior change is limited to failure paths, converting a silent false-success into proper failure detection. Low regression risk and consistent with existing read/write patterns.
**Stable Criteria** - Fixes a real bug affecting users of the cpupower tool (error paths not detected). - Small, contained patch with minimal risk and no new features. - Consistent semantics across the cpupower lib. - Although the commit message does not include an explicit Cc: stable, the change clearly fits stable backport rules.
In summary, updating `return -1;` to `return 0;` in `tools/power/cpupower/lib/cpupower.c:59` ensures callers’ `<= 0` checks work as intended and aligns with existing cpupower I/O conventions. This is a good candidate for backporting.
tools/power/cpupower/lib/cpupower.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/power/cpupower/lib/cpupower.c b/tools/power/cpupower/lib/cpupower.c index ce8dfb8e46abd..d7f7ec6f151c2 100644 --- a/tools/power/cpupower/lib/cpupower.c +++ b/tools/power/cpupower/lib/cpupower.c @@ -56,7 +56,7 @@ unsigned int cpupower_write_sysfs(const char *path, char *buf, size_t buflen) if (numwritten < 1) { perror(path); close(fd); - return -1; + return 0; }
close(fd);