On Mon, Oct 07, 2019 at 10:21:07AM +0100, Jonathan Cameron wrote: > On Sun, 6 Oct 2019 21:14:40 +0300 > Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > > On Sun, Oct 06, 2019 at 09:51:33AM +0100, Jonathan Cameron wrote: > > > On Thu, 26 Sep 2019 14:36:30 +0300 > > > Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > > > > > > On Thu, Sep 26, 2019 at 11:06:39AM +0000, Ardelean, Alexandru wrote: > > > > > On Thu, 2019-09-26 at 11:10 +0300, Dan Carpenter wrote: > > > > > > [External] > > > > > > > > > > > > The "t" variable is unsigned so it can't be less than zero. We really > > > > > > are just trying to prevent divide by zero bugs so just checking against > > > > > > zero is sufficient. > > > > > > I'm not sure that true. It if were signed we'd be detecting that the > > > input from userspace was negative. > > > > It does a really bad job of that though so it raises more questions than > > answers. Maybe just one of the parameters is negative or maybe the > > multiply or the addition overflowed? Should scenarios those be checked? > > > > It turns out none of those situations matter, only divide by zero needs > > to be checked. > > It isn't being nearly paranoid enough. Either val or val2 being > negative is a reason to fault out. Divide by zero needs handling after > that. Obviously divide by zero is the only one that causes a crash but > negatives are going to cause rather 'unexpected' results. The result is that it gets capped at st->chip_info->max_dec_rate so it's not a horrible result. :P I don't know if it's unexpected or not. regards, dan carpenter
