From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3202B222575; Tue, 27 Jan 2026 07:44:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769499843; cv=none; b=Sx00MaoBktV16mnRHln9Hpe897x3wmaseYgY5oeQazWT2PzQXKFOQRWN9bAaDO8Rw6HtGQU1BGKlJRMak8ARKjDpAPzJ7iFCnZ8l9m7q+SwTQk+Ndo4mx8UlvL+ryD51BY8YSX+nEd6cpSUKmR1U+DSmNd/Xm2pTBHddnRTgXVc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769499843; c=relaxed/simple; bh=IPtWJQTW64G5Xd+bumO4kwPOFEJkwG5WjOEOiATZndw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=B7sByQklBEtZzGKcNdFj2rNJ/gnODFn4pmOyLbhgLAdwRkMUT6gjrIbhsXS5Bm7qDxXl/gXtOa6wdp3d5PBQMQYareNl+ifUQOhPBoQTmaWFPTJLEhUFjcfBU6F6nlK07zkH5r5Et/W9ZPp1B3hA8sYUr8o7KLj707E1P8K1fTE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=arTlBACg; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="arTlBACg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1769499841; x=1801035841; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=IPtWJQTW64G5Xd+bumO4kwPOFEJkwG5WjOEOiATZndw=; b=arTlBACgopxV/Z6xe38AtADx06KSyYxCER1Az4wbt+GS3NfPnxL+jxCL zioOWYzVkxcJgEO1xfS+wFouSTlhcyLV3ThO9vQjtn7kFXAFdAur4r6// aR1JPlaftvhpj21lFCn8LUlDSxor4/cVe6zNdmZXRoOUtQTKWAgduRyJ/ jQney8LuiVQXY7RYBHzhdqIN/boN3FvlUOXilRG4WQS9Sjp0QNV2B3Xgz 7FH5n5bw8ymGlI8HfiCplJecOEFqqA7ND2L92a/P95U0uF9pNBQalaD3P 8c10+wobhwlEQOMbZMzJIREbqKwX0n6myfGZrXANXaS9pbWMaxVOHi7LT Q==; X-CSE-ConnectionGUID: jMljNdpOQSiRUULqZoGySg== X-CSE-MsgGUID: BIvJme4FSIieHji38/d7nw== X-IronPort-AV: E=McAfee;i="6800,10657,11683"; a="74550438" X-IronPort-AV: E=Sophos;i="6.21,256,1763452800"; d="scan'208";a="74550438" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2026 23:44:01 -0800 X-CSE-ConnectionGUID: 3Epk6UwgSZKCxTGSc3p/Ig== X-CSE-MsgGUID: bEUQBlwxSRaiJHGCMTmQag== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,256,1763452800"; d="scan'208";a="207522115" Received: from egrumbac-mobl6.ger.corp.intel.com (HELO localhost) ([10.245.245.248]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2026 23:43:57 -0800 Date: Tue, 27 Jan 2026 09:43:55 +0200 From: Andy Shevchenko To: Rodrigo Alencar <455.rodrigo.alencar@gmail.com>, Dmitry Antipov , Rasmus Villemoes , Kees Cook , Petr Mladek Cc: rodrigo.alencar@analog.com, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org, Jonathan Cameron , David Lechner , Andy Shevchenko , Lars-Peter Clausen , Michael Hennerich Subject: Re: [PATCH v5 2/8] iio: core: add fixed point parsing with 64-bit parts Message-ID: References: <20260123-adf41513-iio-driver-v5-2-2dce812a2dda@analog.com> Precedence: bulk X-Mailing-List: linux-iio@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo 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