Received-SPF: pass (google.com: domain of linux-kernel+bounces-5560-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20231219031444.91752-1-bo.ye@mediatek.com> <e807b180b074419ba4f1d1ff8a4c1a80@AcuMS.aculab.com>
In-Reply-To: <e807b180b074419ba4f1d1ff8a4c1a80@AcuMS.aculab.com>
From: "Rafael J. Wysocki" <rafael@kernel.org>
Date: Tue, 19 Dec 2023 17:30:00 +0100
Message-ID: <CAJZ5v0gLDZtfGhowxSM+nwBCM80y6sDR56fYZrHNGaRFK1oGyw@mail.gmail.com>
Subject: Re: [PATCH v2] fix overflow in idle exit_latency
To: David Laight <David.Laight@aculab.com>
Cc: Bo Ye <bo.ye@mediatek.com>, "Rafael J. Wysocki" <rafael@kernel.org>, 
	Daniel Lezcano <daniel.lezcano@linaro.org>, Matthias Brugger <matthias.bgg@gmail.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, 
	"yongdong.zhang@mediatek.com" <yongdong.zhang@mediatek.com>, C Cheng <C.Cheng@mediatek.com>, 
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, 
	"linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, 
	"linux-mediatek@lists.infradead.org" <linux-mediatek@lists.infradead.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 19, 2023 at 5:24=E2=80=AFPM David Laight <David.Laight@aculab.c=
om> wrote:
>
> From: Bo Ye
> > Sent: 19 December 2023 03:15
> >
> > From: C Cheng <C.Cheng@mediatek.com>
> >
> > In detail:
> >
> > In C language, when you perform a multiplication operation, if
> > both operands are of int type, the multiplication operation is
> > performed on the int type, and then the result is converted to
> > the target type. This means that if the product of int type
> > multiplication exceeds the range that int type can represent,
> >  an overflow will occur even if you store the result in a
> > variable of int64_t type.
> >
> > For a multiplication of two int values, it is better to use
> > mul_u32_u32() rather than s->exit_latency_ns =3D s->exit_latency *
> > NSEC_PER_USEC to avoid potential overflow happenning.
> >
> > Signed-off-by: C Cheng <C.Cheng@mediatek.com>
> > Signed-off-by: Bo Ye <bo.ye@mediatek.com>
> > ---
> > Change in v2:
> > -remove Change-ID
> > -correct patch author name
> > -replace multiplication of two int values with mul_u32_u32
> > -refine commit message
> > ---
> >  drivers/cpuidle/driver.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> > index d9cda7f6ccb9..cf5873cc45dc 100644
> > --- a/drivers/cpuidle/driver.c
> > +++ b/drivers/cpuidle/driver.c
> > @@ -16,6 +16,7 @@
> >  #include <linux/cpumask.h>
> >  #include <linux/tick.h>
> >  #include <linux/cpu.h>
> > +#include <linux/math64.h>
> >
> >  #include "cpuidle.h"
> >
> > @@ -187,7 +188,7 @@ static void __cpuidle_driver_init(struct cpuidle_dr=
iver *drv)
> >                       s->target_residency =3D div_u64(s->target_residen=
cy_ns, NSEC_PER_USEC);
> >
> >               if (s->exit_latency > 0)
> > -                     s->exit_latency_ns =3D s->exit_latency * NSEC_PER=
_USEC;
> > +                     s->exit_latency_ns =3D mul_u32_u32(s->exit_latenc=
y, NSEC_PER_USEC);
>
> Just force either side of the multiply to a 64bit unsigned type.
> The compiler will then DTRT which is likely to be better code than
> whatever mul_u32_u32() generates.

So why is it there?

The default implementation of mul_u32_u32() is to cast its first
argument to u64 before the multiplication AFAICS.

> In any case is the 'exit_latency' ever going to be greater than 4 seconds=
?
> In which case the 32bit multiply will never overflow.

So this is more of a theoretical thing found by some static analysis
tool or similar.

> >               else if (s->exit_latency_ns < 0)
> >                       s->exit_latency_ns =3D  0;
> >               else
> > --