[BUG] clamp() low limit 0 greater than high limit points[1] - 1

[BUG] clamp() low limit 0 greater than high limit points[1] - 1

[Paul E. McKenney]

Hello!

Recent -next trees have failed allmodconfig builds with the following
build error:

drivers/hwmon/minisforum-um780xtx.c: In function ‘um780xtx_sys_point_temp_store’:
  HDRTEST usr/include/linux/hash_info.h
././include/linux/compiler_types.h:702:45: error: call to ‘__compiletime_assert_727’ declared with attribute error: clamp() low limit 0 greater than high limit points[1] - 1
  702 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |                                             ^
././include/linux/compiler_types.h:683:25: note: in definition of macro ‘__compiletime_assert’
  683 |                         prefix ## suffix();                             \
      |                         ^~~~~~
././include/linux/compiler_types.h:702:9: note: in expansion of macro ‘_compiletime_assert’
  702 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |         ^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:40:37: note: in expansion of macro ‘compiletime_assert’
   40 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
      |                                     ^~~~~~~~~~~~~~~~~~
./include/linux/minmax.h:188:9: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
  188 |         BUILD_BUG_ON_MSG(statically_true(ulo > uhi),                            \
      |         ^~~~~~~~~~~~~~~~
./include/linux/minmax.h:195:9: note: in expansion of macro ‘__clamp_once’
  195 |         __clamp_once(type, val, lo, hi, __UNIQUE_ID(v_), __UNIQUE_ID(l_), __UNIQUE_ID(h_))
      |         ^~~~~~~~~~~~
./include/linux/minmax.h:231:32: note: in expansion of macro ‘__careful_clamp’
  231 | #define clamp_val(val, lo, hi) __careful_clamp(typeof(val), val, lo, hi)
      |                                ^~~~~~~~~~~~~~~
drivers/hwmon/minisforum-um780xtx.c:203:25: note: in expansion of macro ‘clamp_val’
  203 |                 value = clamp_val(value, 0, points[1] - 1);
      |                         ^~~~~~~~~

I must confess to being unsure what fix would be appropriate when
points[1] is zero or negative.

Help?

							Thanx, Paul

[PATCH] hwmon: (minisforum-um780xtx) Fix clamp() build failure with GCC 11

[Sebastián Peyrott]

GCC 11 fails to build the driver:

  error: call to '__compiletime_assert_727' declared with attribute error:
  clamp() low limit 0 greater than high limit points[1] - 1

The store function returns -EIO unless points[0] < points[1], so
points[1] - 1 cannot be negative when the clamp is reached. GCC 11 jump
threading, however, duplicates the clamp() limit check and does not prune
the copy in which points[1] is zero, so the compile-time check in clamp()
fires on an unreachable path. GCC 8 to 10 and 12 to 16 accept the code.

Select both limits first and use a single clamp_val(). This does not
change behavior.

Fixes: 9d980da93bbc ("hwmon: Add Minisforum UM780 XTX EC monitoring and fan control")
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Closes: https://lore.kernel.org/r/fda0e59f-20e1-4a94-a714-288940dcdd37@paulmck-laptop
Assisted-by: LLM
Signed-off-by: Sebastián Peyrott <speyrott@gmail.com>
---
Reproduced on next-20261014 (x86_64) with GCC 11.5.0, both with
allmodconfig and with defconfig plus this driver; GCC 8.5, 9.5, 10.5,
12.4, 13.4, 14.4, 15.3 and 16.1 build the unmodified driver. With this
change, the driver builds without warnings with W=1 using GCC 11, 13, 14,
15 and 16 (x86_64 allmodconfig) and GCC 16 (i386 allmodconfig). A small
standalone reproducer of the clamp() pattern fails only with GCC 11, and
the patched form builds with GCC 8 through 16.

Tested on the UM780 XTX: the installed driver and this version produce
identical rounding and clamping results for both system fan thresholds,
with every value verified against the EC registers and the original
thresholds restored afterwards. Module load and unload are also clean.

An LLM-based coding assistant helped reproduce and analyse the failure
and prepare this patch. I reviewed the change and the test results.

 drivers/hwmon/minisforum-um780xtx.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/hwmon/minisforum-um780xtx.c b/drivers/hwmon/minisforum-um780xtx.c
index f5d6e18cb651..962ebf41ffb7 100644
--- a/drivers/hwmon/minisforum-um780xtx.c
+++ b/drivers/hwmon/minisforum-um780xtx.c
@@ -180,7 +180,7 @@ static ssize_t um780xtx_sys_point_temp_store(struct device *dev,
 	struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
 	u8 points[2];
 	u8 readback;
-	long value;
+	long value, lo, hi;
 	int ret;
 
 	ret = kstrtol(buf, 10, &value);
@@ -198,13 +198,15 @@ static ssize_t um780xtx_sys_point_temp_store(struct device *dev,
 	if (points[0] >= points[1] || points[1] >= data->sys_point3)
 		return -EIO;
 
+	if (!sattr->index) {
+		lo = 0;
+		hi = points[1] - 1;
+	} else {
+		lo = points[0] + 1;
+		hi = data->sys_point3 - 1;
+	}
 	value = DIV_ROUND_CLOSEST(value, 1000);
-	if (!sattr->index)
-		value = clamp_val(value, 0, points[1] - 1);
-	else
-		value = clamp_val(value, points[0] + 1,
-				  data->sys_point3 - 1);
-	points[sattr->index] = value;
+	points[sattr->index] = clamp_val(value, lo, hi);
 
 	ret = ec_write(um780xtx_sys_point_offsets[sattr->index],
 		       points[sattr->index]);

base-commit: 4781ca52761e666cf18b591e6bb0478396c90320
-- 
2.54.0

Re: [PATCH] hwmon: (minisforum-um780xtx) Fix clamp() build failure with GCC 11

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] hwmon: minisforum-um780xtx: integer overflow in DIV_ROUND_CLOSEST
--

commit 37b4941cfec26b0afeccdcd44aef6f32fe1e9d55
Author: Sebastián Peyrott <speyrott@gmail.com>

hwmon: (minisforum-um780xtx) Fix clamp() build failure with GCC 11

This patch fixes a GCC 11 build failure by selecting clamping limits early
and using a single clamp_val() execution. This prevents GCC jump threading
from duplicating the limit check and firing an unreachable compile-time
assertion.

Closes: https://lore.kernel.org/r/fda0e59f-20e1-4a94-a714-288940dcdd37@paulmck-laptop

> diff --git a/drivers/hwmon/minisforum-um780xtx.c b/drivers/hwmon/minisforum-um780xtx.c
> index f5d6e18cb651f..962ebf41ffb7f 100644
> --- a/drivers/hwmon/minisforum-um780xtx.c
> +++ b/drivers/hwmon/minisforum-um780xtx.c

[ ... ]

> @@ -198,13 +198,15 @@ static ssize_t um780xtx_sys_point_temp_store(struct device *dev,
>  	if (points[0] >= points[1] || points[1] >= data->sys_point3)
>  		return -EIO;
>  
> +	if (!sattr->index) {
> +		lo = 0;
> +		hi = points[1] - 1;
> +	} else {
> +		lo = points[0] + 1;
> +		hi = data->sys_point3 - 1;
> +	}
>  	value = DIV_ROUND_CLOSEST(value, 1000);
> -	if (!sattr->index)
> -		value = clamp_val(value, 0, points[1] - 1);
> -	else
> -		value = clamp_val(value, points[0] + 1,
> -				  data->sys_point3 - 1);
> -	points[sattr->index] = value;
> +	points[sattr->index] = clamp_val(value, lo, hi);

[Severity: Low]
Can this arithmetic result in an integer overflow for extreme inputs?

When a user writes an extremely large value like LONG_MAX to the sysfs file
in um780xtx_sys_point_temp_store(), the unbounded value is passed directly
to DIV_ROUND_CLOSEST(value, 1000) before it is clamped. 

Because DIV_ROUND_CLOSEST adds half the divisor before dividing, an extreme
positive input can overflow and wrap around to a negative number. This would
cause the value to incorrectly clamp to the minimum bound (lo) instead of
the maximum bound (hi). Conversely, an extreme negative input could underflow
and improperly clamp to hi.

Would it be safer to pre-clamp the value before calling DIV_ROUND_CLOSEST
to prevent this overflow? Many other hwmon drivers clamp the input bounds
first prior to performing the division to avoid this behavior.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014214522.243253-1-speyrott@gmail.com?part=1

Re: [PATCH] hwmon: (minisforum-um780xtx) Fix clamp() build failure with GCC 11

[Paul E. McKenney]

On Wed, Oct 14, 2026 at 06:45:22PM -0300, Sebastián Peyrott wrote:
> GCC 11 fails to build the driver:
> 
>   error: call to '__compiletime_assert_727' declared with attribute error:
>   clamp() low limit 0 greater than high limit points[1] - 1
> 
> The store function returns -EIO unless points[0] < points[1], so
> points[1] - 1 cannot be negative when the clamp is reached. GCC 11 jump
> threading, however, duplicates the clamp() limit check and does not prune
> the copy in which points[1] is zero, so the compile-time check in clamp()
> fires on an unreachable path. GCC 8 to 10 and 12 to 16 accept the code.
> 
> Select both limits first and use a single clamp_val(). This does not
> change behavior.
> 
> Fixes: 9d980da93bbc ("hwmon: Add Minisforum UM780 XTX EC monitoring and fan control")
> Reported-by: Paul E. McKenney <paulmck@kernel.org>
> Closes: https://lore.kernel.org/r/fda0e59f-20e1-4a94-a714-288940dcdd37@paulmck-laptop
> Assisted-by: LLM
> Signed-off-by: Sebastián Peyrott <speyrott@gmail.com>

Thank you!!!

Tested-by: Paul E. McKenney <paulmck@kernel.org>

Though it would be *way* better to fold this back into the original
commit to avoid breaking bisection.

							Thanx, Paul

> ---
> Reproduced on next-20261014 (x86_64) with GCC 11.5.0, both with
> allmodconfig and with defconfig plus this driver; GCC 8.5, 9.5, 10.5,
> 12.4, 13.4, 14.4, 15.3 and 16.1 build the unmodified driver. With this
> change, the driver builds without warnings with W=1 using GCC 11, 13, 14,
> 15 and 16 (x86_64 allmodconfig) and GCC 16 (i386 allmodconfig). A small
> standalone reproducer of the clamp() pattern fails only with GCC 11, and
> the patched form builds with GCC 8 through 16.
> 
> Tested on the UM780 XTX: the installed driver and this version produce
> identical rounding and clamping results for both system fan thresholds,
> with every value verified against the EC registers and the original
> thresholds restored afterwards. Module load and unload are also clean.
> 
> An LLM-based coding assistant helped reproduce and analyse the failure
> and prepare this patch. I reviewed the change and the test results.
> 
>  drivers/hwmon/minisforum-um780xtx.c | 16 +++++++++-------
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/hwmon/minisforum-um780xtx.c b/drivers/hwmon/minisforum-um780xtx.c
> index f5d6e18cb651..962ebf41ffb7 100644
> --- a/drivers/hwmon/minisforum-um780xtx.c
> +++ b/drivers/hwmon/minisforum-um780xtx.c
> @@ -180,7 +180,7 @@ static ssize_t um780xtx_sys_point_temp_store(struct device *dev,
>  	struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
>  	u8 points[2];
>  	u8 readback;
> -	long value;
> +	long value, lo, hi;
>  	int ret;
>  
>  	ret = kstrtol(buf, 10, &value);
> @@ -198,13 +198,15 @@ static ssize_t um780xtx_sys_point_temp_store(struct device *dev,
>  	if (points[0] >= points[1] || points[1] >= data->sys_point3)
>  		return -EIO;
>  
> +	if (!sattr->index) {
> +		lo = 0;
> +		hi = points[1] - 1;
> +	} else {
> +		lo = points[0] + 1;
> +		hi = data->sys_point3 - 1;
> +	}
>  	value = DIV_ROUND_CLOSEST(value, 1000);
> -	if (!sattr->index)
> -		value = clamp_val(value, 0, points[1] - 1);
> -	else
> -		value = clamp_val(value, points[0] + 1,
> -				  data->sys_point3 - 1);
> -	points[sattr->index] = value;
> +	points[sattr->index] = clamp_val(value, lo, hi);
>  
>  	ret = ec_write(um780xtx_sys_point_offsets[sattr->index],
>  		       points[sattr->index]);
> 
> base-commit: 4781ca52761e666cf18b591e6bb0478396c90320
> -- 
> 2.54.0
>