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
