lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260207165938.59d6895f@jic23-huawei>
Date: Sat, 7 Feb 2026 16:59:38 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Nuno Sá <noname.nuno@...il.com>
Cc: Rodrigo Alencar <455.rodrigo.alencar@...il.com>,
 rodrigo.alencar@...log.com, linux-kernel@...r.kernel.org,
 linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
 linux-doc@...r.kernel.org, David Lechner <dlechner@...libre.com>, Andy
 Shevchenko	 <andy@...nel.org>, Lars-Peter Clausen <lars@...afoo.de>,
 Michael Hennerich	 <Michael.Hennerich@...log.com>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH v6 2/8] iio: core: add fixed point parsing with 64-bit
 parts

On Tue, 03 Feb 2026 10:04:01 +0000
Nuno Sá <noname.nuno@...il.com> wrote:

> On Tue, 2026-02-03 at 09:26 +0000, Rodrigo Alencar wrote:
> > On 26/02/02 09:57AM, Nuno Sá wrote:  
> > > On Fri, 2026-01-30 at 10:06 +0000, Rodrigo Alencar via B4 Relay wrote:  
> > > > From: Rodrigo Alencar <rodrigo.alencar@...log.com>
> > > > 
> > > > Add iio_str_to_fixpoint64() function that leverages simple_strtoull()
> > > > to parse numbers from a string.
> > > > A helper function __iio_str_to_fixpoint64() replaces
> > > > __iio_str_to_fixpoint() implementation, extending its usage for
> > > > 64-bit fixed-point parsing.  
> > 
> > ...
> >   
> > > >  /**
> > > >   * __iio_str_to_fixpoint() - Parse a fixed-point number from a string
> > > >   * @str: The string to parse
> > > > @@ -895,63 +1026,43 @@ static ssize_t iio_read_channel_info_avail(struct device *dev,
> > > >  static int __iio_str_to_fixpoint(const char *str, int fract_mult,
> > > >  				 int *integer, int *fract, bool scale_db)
> > > >  {
> > > > -	int i = 0, f = 0;
> > > > -	bool integer_part = true, negative = false;
> > > > +	s64 integer64, fract64;
> > > > +	int ret;
> > > >  
> > > > -	if (fract_mult == 0) {
> > > > -		*fract = 0;
> > > > +	ret = __iio_str_to_fixpoint64(str, fract_mult, &integer64, &fract64,
> > > > +				      scale_db);
> > > > +	if (ret)
> > > > +		return ret;  
> > > 
> > > I know it feels tempting to do the above while adding the 64bit variant. But isn't the
> > > overflow safety also an issue on the 32bit variant? IMO, we should first have a patch
> > > adding the overflow safety with a Fixes tag and then add 64bit support.  
> > 
> > I think handling 64-bit support after taclking the overflow issue
> > would require changes on top of previous ones, which might get a messy
> > commit history, no? Mostly because the 64-bit variant of the function
> > is being used inside the 32-bit one. Also, the added auxiliary function
> > that implements the overflow check parses u64, which allowed for the
> > removal of the while loop in the __iio_str_to_fixpoint() implementation.  
> 
> Typically we do fixes before because we might want to backport them and we just want to backport the
> fix (so not the 64bit support). But we never really had any known issues with the current API
> (AFAIK) so it might be ok as-is. Will defer to Jonathan.

When we say overflow, I assume we just get the wrong value?  If so
then I doubt anyone ever noticed it.  Worth tidying up as a useability
improvement but not sure it's worth back porting.

Jonathan

> 
> - Nuno Sá
> > before this assignment.
> >    


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ