Re: [PATCH rdma-next] lib/dim: Prevent overflow in calculation of ratio statistics

[Jason Gunthorpe <jgg@mellanox.com>]

On Sun, Jul 14, 2019 at 01:54:59PM +0300, Leon Romanovsky wrote:
> On Fri, Jul 12, 2019 at 03:23:20PM +0000, Jason Gunthorpe wrote:
> > On Fri, Jul 12, 2019 at 09:03:09AM +0300, Leon Romanovsky wrote:
> > > On Thu, Jul 11, 2019 at 05:31:14PM +0000, Jason Gunthorpe wrote:
> > > > On Thu, Jul 11, 2019 at 08:19:22PM +0300, Leon Romanovsky wrote:
> > > > > On Thu, Jul 11, 2019 at 04:11:07PM +0000, Jason Gunthorpe wrote:
> > > > > > On Thu, Jul 11, 2019 at 06:47:34PM +0300, Leon Romanovsky wrote:
> > > > > > > > > diff --git a/lib/dim/dim.c b/lib/dim/dim.c
> > > > > > > > > index 439d641ec796..38045d6d0538 100644
> > > > > > > > > +++ b/lib/dim/dim.c
> > > > > > > > > @@ -74,8 +74,8 @@ void dim_calc_stats(struct dim_sample *start, struct dim_sample *end,
> > > > > > > > >  					delta_us);
> > > > > > > > >  	curr_stats->cpms = DIV_ROUND_UP(ncomps * USEC_PER_MSEC, delta_us);
> > > > > > > > >  	if (curr_stats->epms != 0)
> > > > > > > > > -		curr_stats->cpe_ratio =
> > > > > > > > > -				(curr_stats->cpms * 100) / curr_stats->epms;
> > > > > > > > > +		curr_stats->cpe_ratio = DIV_ROUND_DOWN_ULL(
> > > > > > > > > +			curr_stats->cpms * 100, curr_stats->epms);
> > > > > > > >
> > > > > > > > This will still potentially overfow the 'int' for cpe_ratio if epms <
> > > > > > > > 100 ?
> > > > > > >
> > > > > > > I assumed that assignment to "unsigned long long" will do the trick.
> > > > > > > https://elixir.bootlin.com/linux/latest/source/include/linux/kernel.h#L94
> > > > > >
> > > > > > That only protects the multiply, the result of DIV_ROUND_DOWN_ULL is
> > > > > > casted to int.
> > > > >
> > > > > It is ok, the result is "int" and it will be small, 100 in multiply
> > > > > represents percentage.
> > > >
> > > > Percentage would be divide by 100..
> > > >
> > > > Like I said it will overflow if epms < 100 ...
> > >
> > > It is unlikely to happen because cpe_ratio is between 0 to 100 and cpms
> > > * 100 is not large at all.
> > >
> > > UBSAN error is "theoretical" overflow.
> >
> > ? UBSAN is not theoretical, it only triggers if something actually
> > happens. So in this case cpms*100 was very large and overflowed.
> >
> > Maybe it shouldn't be and that is the actual bug, but if we overflowed
> > with cpms*100, then epms must be > 100 or we still overflow the
> > divide.
> 
> I think that the real bug is cpms became too big.

So I'll drop the patch until someone figures out what is happening

Jason