linux-kernel - Re: [PATCH] iio: gts-helper: Fix division loop

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240122192448.1493ccf7@jic23-huawei>
Date: Mon, 22 Jan 2024 19:24:48 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: David Laight <David.Laight@...LAB.COM>
Cc: 'Matti Vaittinen' <mazziesaccount@...il.com>, Subhajit Ghosh
 <subhajit.ghosh@...aklogic.com>, Matti Vaittinen
 <matti.vaittinen@...rohmeurope.com>, Lars-Peter Clausen <lars@...afoo.de>,
 "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] iio: gts-helper: Fix division loop

On Mon, 22 Jan 2024 16:27:13 +0000
David Laight <David.Laight@...LAB.COM> wrote:

> From: Matti Vaittinen
> > Sent: 22 January 2024 06:51
> > 
> > On 1/19/24 13:56, Subhajit Ghosh wrote:  
> > > On 8/1/24 02:52, Jonathan Cameron wrote:  
> > >> On Thu, 4 Jan 2024 11:34:28 +0200
> > >> Matti Vaittinen <mazziesaccount@...il.com> wrote:
> > >>  
> > >>> The loop based 64bit division may run for a long time when dividend is a
> > >>> lot bigger than the divider. Replace the division loop by the
> > >>> div64_u64() which implementation may be significantly faster.
> > >>>
> > >>> Signed-off-by: Matti Vaittinen <mazziesaccount@...il.com>
> > >>> Fixes: 38416c28e168 ("iio: light: Add gain-time-scale helpers")  
> > >>
> > >> Hmm. Fix or not perf improvement?  I'm going to take the middle ground
> > >> and leave the fixes tag, but not rush this in.
> > >>
> > >> So applied to the togreg branch of iio.git and for now just pushed out
> > >> as testing for 0-day etc to take a look before I rebase that tree after
> > >> rc1.
> > >>
> > >>
> > >>  
> > >>> ---
> > >>>
> > >>> I've implemented also a fixup series for supporting rounding of
> > >>> gains/scales:
> > >>>  
> > https://lore.kernel.org/lkml/37d3aa193e69577353d314e94463a08d488ddd8d.1701780964.git.mazziesaccount@gm
> > ail.com/  
> > >>>
> > >>> That series does also remove the offending loop.
> > >>>
> > >>> We don't currently have any in-tree users of GTS helpers which would
> > >>> need the rounding support so pushing the rounding is not urgent (and I
> > >>> haven't heard of Subjahit whose driver required the rounding). Hence, we
> > >>> may want to only take this loop fix in for now (?) and reconsider
> > >>> rounding when someone need that.  
> 
> Why did I look as this crappy code :-)
> I think the change breaks the rounding.
> For 'normal' values I think you just want:
> 	return 1 + (max - 1)/scale.
> 
> The 'avoid overflow' test isn't needed if you subtract 1 from max.
> (Rather than return (max + scale - 1)/scale; where the add can overflow.
> But you do need something to return 1 (or error) if max is zero.
> 
> 	David
Too late for my brain to process this, so with an abundance
of caution I've dropped it for now (I'm going to push out as hopefully not
rebasing in a few mins)

J

> 
> > >>>
> > >>> Jonathan, what's your take on this?  
> > >> Agreed - let us wait for the rounding to have a user, but makes sense
> > >> to tidy this corner up in the meantime.
> > >>
> > >> Thanks,
> > >>
> > >> Jonathan
> > >>  
> > >>>
> > >>>   drivers/iio/industrialio-gts-helper.c | 5 ++---
> > >>>   1 file changed, 2 insertions(+), 3 deletions(-)
> > >>>
> > >>> diff --git a/drivers/iio/industrialio-gts-helper.c
> > >>> b/drivers/iio/industrialio-gts-helper.c
> > >>> index 7653261d2dc2..abcab2d38589 100644
> > >>> --- a/drivers/iio/industrialio-gts-helper.c
> > >>> +++ b/drivers/iio/industrialio-gts-helper.c
> > >>> @@ -34,7 +34,7 @@
> > >>>   static int iio_gts_get_gain(const u64 max, const u64 scale)
> > >>>   {
> > >>>       u64 full = max;
> > >>> -    int tmp = 1;
> > >>> +    int tmp = 0;
> > >>>       if (scale > full || !scale)
> > >>>           return -EINVAL;
> > >>> @@ -48,8 +48,7 @@ static int iio_gts_get_gain(const u64 max, const
> > >>> u64 scale)
> > >>>           tmp++;
> > >>>       }
> > >>> -    while (full > scale * (u64)tmp)
> > >>> -        tmp++;
> > >>> +    tmp += div64_u64(full, scale);
> > >>>       return tmp;
> > >>>   }
> > >>>
> > >>> base-commit: 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab  
> > >>
> > >>  
> > > Hi Matti,
> > >
> > > Your fix works beautifully with the latest version of apds9306 driver
> > > which I am working on.
> > > All available scale values can be set without any errors. Thank you.  
> > 
> > Thanks for testing Subhajit! Just to ensure we have no miscommunication
> > - did you test just this division fix, or the rounding fix here:
> > https://lore.kernel.org/lkml/37d3aa193e69577353d314e94463a08d488ddd8d.1701780964.git.mazziesaccount@gm
> > ail.com/
> >   
> > > Moving to a new city with a new full time job with the assumption of
> > > getting more time
> > > for my list of opensource projects and contributions proved to be
> > > utterly wrong!  
> > 
> > Well, I can't blame you :) Being in a new work at new city sounds like
> > you have a lot on your plate right now. Give it half a year and things
> > will stabilize though :) Oh, and falsely assuming that "when XXX, I will
> > have the time to do YYY" - been there done that :)
> > 
> > Good luck on the new work and city!
> > 
> > Yours,
> > 	-- Matti
> > 
> > --
> > Matti Vaittinen
> > Linux kernel developer at ROHM Semiconductors
> > Oulu Finland
> > 
> > ~~ When things go utterly wrong vim users can always type :help! ~~
> >   
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)