Re: [PATCH v5 2/8] iio: core: add fixed point parsing with 64-bit parts

[Andy Shevchenko <andriy.shevchenko@intel.com>]

Remove DT related people and ML and add others based on the links I posted
below.

On Mon, Jan 26, 2026 at 04:55:13PM +0000, Rodrigo Alencar wrote:
> On 26/01/26 06:07PM, Andy Shevchenko wrote:
> > On Mon, Jan 26, 2026 at 03:30:44PM +0000, Rodrigo Alencar wrote:
> > > On 26/01/26 03:20PM, Rodrigo Alencar wrote:
> > > > On 26/01/26 04:53PM, Andy Shevchenko wrote:
> > > > > On Mon, Jan 26, 2026 at 02:26:20PM +0000, Rodrigo Alencar wrote:

...

> > > > > Why? Can you elaborate how checking amount of digits is different to
> > > > > check_mul_overflow()?
> > > > 
> > > > consider U64_MAX = 18_446_744_073_709_551_615 as the limit:
> > > > - 19_000_000_000_000_000_000 contains the same amount of digits but overflows.
> > > > - 18_446_744_073_710_000_000 contains the same amount of digits but overflows.
> > > > 
> > > > to catch those cases, we need to check for the overflow, everytime we read a
> > > > character and accumulate:
> > > > 
> > > > u64 acc;
> > > > 
> > > > while(isdigit(*str))
> > > > 	if (check_mul_overflow(acc, 10, &acc) ||
> > > > 	    check_add_overflow(acc, *str - '0', &acc))
> > > > 		return -EOVERFLOW;
> > > > 
> > > > *res = acc;
> > > > 
> > > > acc can get weird results if not checked. 
> > > 
> > > Thinking about it again, that check could be done only in the last step
> > > (20th for u64)
> > 
> > Does kstrto*() also perform only last check? I think they do for each
> > iteration.
> 
> It does the following:
> 
> ...
> 		if (unlikely(res & (~0ull << 60))) {
> 			if (res > div_u64(ULLONG_MAX - val, base))
> 				rv |= KSTRTOX_OVERFLOW;
> 		}
> ...
> 
> so overflow is checked when either one of the 4 MSbits are set.
> 
> for now, I am thinking of something like:
> 
> static ssize_t iio_safe_strtou64(const char *str, const char **endp,
> 				 size_t max_chars, u64 *result)
> {
> 	u64 digit, acc = 0;
> 	size_t idx = 0;
> 
> 	while (isdigit(*str) && idx < max_chars) {
> 		digit = *str - '0';
> 		if (unlikely(idx > 19)) {
> 			if (check_mul_overflow(acc, 10, &acc) ||
> 			    check_add_overflow(acc, digit, &acc))
> 				return -EOVERFLOW;
> 		} else {
> 			acc = acc * 10 + digit;
> 		}
> 		str++;
> 		idx++;
> 	}
> 
> 	*endp = str;
> 	*result = acc;
> 	return idx;
> }
> 
> which would help the truncation when parsing the fractional part
> with max_chars, avoiding a div64_u64() to adjust precision:
> 
> ...
> 	digit_count = iio_safe_strtou64(str, &end, SIZE_MAX, &i);
> 	if (digit_count < 0)
> 		return digit_count;
> 
> 	if (precision && *end == '.') {
> 		str = end + 1;
> 		digit_count = iio_safe_strtou64(str, &end, precision, &f);
> 		if (digit_count < 0)
> 			return digit_count;
> 
> 		if (digit_count < precision) /* scale up */
> 			f *= int_pow(10, precision - digit_count);
> 
> 		while (isdigit(*end)) /* truncate */
> 			end++;
> 	}
> ...
> 
> but I understand you would not like this approach, because it does not use
> simple_strtoull() or kstrtoull(). Problem is simple_strtoull() is not
> overflow-safe and kstrtoull() does not allow to track a pointer to end
> of the string.
> 
> Given that the current implementation of iio_str_to_fixpoint() is not using
> simple_strtoull() I am not seeing an issue with this approach.

I believe this is the goal, id est to get rid of the code duplication.
The idea is not exactly in _using_ simple_strto*() or kstrto*(), but
deriving the common parts that can be reused here. For simplicity, we
may leave iio_str_to_fixpoint() alone for now (as you mentioned it
doesn't share currently the code, so can be addressed later on)
and try to provide a treewide available safe_strto*().

Browsing through lore.kernel.org I found these
(in backward chronological order):

https://lore.kernel.org/linux-hardening/20260126162059.357467-1-dmantipov@yandex.ru/
https://lore.kernel.org/lkml/d6c3b369-9777-9986-f41f-3f3a4f85d64c@rasmusvillemoes.dk/
https://lore.kernel.org/lkml/CA+55aFyC7N4S65UVrp0Hcefb5AsMPqGn_bco6tFL+JZ0m3nh=A@mail.gmail.com/

which suggests that the problems are known and there are attempts to address them.
Perhaps we should consider what Rasmus started 6 years ago...

-- 
With Best Regards,
Andy Shevchenko