[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fc89fa33a09e59bf3f787015a875e1b3c593f9a4.camel@mediatek.com>
Date: Tue, 18 Jul 2023 15:30:43 +0000
From: Jason-JH Lin (林睿祥)
<Jason-JH.Lin@...iatek.com>
To: CK Hu (胡俊光) <ck.hu@...iatek.com>,
"amergnat@...libre.com" <amergnat@...libre.com>,
"chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>,
"David.Laight@...LAB.COM" <David.Laight@...LAB.COM>,
"angelogioacchino.delregno@...labora.com"
<angelogioacchino.delregno@...labora.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>,
Singo Chang (張興國)
<Singo.Chang@...iatek.com>,
Johnson Wang (王聖鑫)
<Johnson.Wang@...iatek.com>,
Jason-ch Chen (陳建豪)
<Jason-ch.Chen@...iatek.com>,
Shawn Sung (宋孝謙)
<Shawn.Sung@...iatek.com>,
Nancy Lin (林欣螢) <Nancy.Lin@...iatek.com>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@...iatek.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"matthias.bgg@...il.com" <matthias.bgg@...il.com>
Subject: Re: [PATCH v3 3/4] drm/mediatek: Add casting before assign
Hi David,
Thanks for the reviews.
On Mon, 2023-07-17 at 13:17 +0000, David Laight wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> From: Jason-JH Lin
> > Sent: 14 July 2023 07:46
> >
> > Hi CK,
> >
> > Thanks for the reviews.
> >
> > On Fri, 2023-07-14 at 05:45 +0000, CK Hu (胡俊光) wrote:
> > > Hi, Jason:
> > >
> > > On Wed, 2023-06-21 at 18:22 +0800, Jason-JH.Lin wrote:
> > > > 1. Add casting before assign to avoid the unintentional integer
> > > > overflow or unintended sign extension.
> > > > 2. Add a int varriable for multiplier calculation instead of
> > > > calculating
> > > > different types multiplier with dma_addr_t varriable
> directly.
> > >
> > > I agree with these modification, but the title does not match the
> > > modification.
> > >
> > > Regards,
> > > CK
> >
> > I'll change the title and commit msg at the next version below:
> >
> > Fix unintentional integer overflow in multiplying different types
> >
> > 1. Instead of multiplying 2 variable of different types. Change to
> > assign a value of one variable and then multiply the other
> variable.
> >
> > 2. Add a int variable for multiplier calculation instead of
> calculating
> > different types multiplier with dma_addr_t variable directly.
>
> I'm pretty sure the patch makes absolutely no difference.
> In C all arithmetic is done with char/short (inc. unsigned)
> promoted to int.
`char/short promoted to int` could you give me an example or more
detail for this?
I can't really understand about that. Thanks~
>
> So the only likely overflow is if the values exceed 2^31.
> Since the temporaries you are using are 'int' this isn't true.
>
According to the modification:
+ int offset;
...
- addr += (new_state->src.x1 >> 16) * fb->format->cpp[0];
- addr += (new_state->src.y1 >> 16) * pitch;
+ offset = (new_state->src.x1 >> 16) * fb->format->cpp[0];
+ addr += offset;
+ offset = (new_state->src.y1 >> 16) * pitch;
+ addr += offset;
The main reasons why I use `int offset` here is that
src.x1 and src.y1 are `32bits int` defined in
struct drm_rect {
int x1, y1, x2, y2;
};
We know that the values of `x1 * cpp` and `y1 * pitch` would never
cause 32bits overflow actually.
So I just add the same type `int offset` as a 32bits variable to avoid
Coverity checker catching the unintentional overflow of
`64bits addr += 32bits x1 * 8bits cpp` and
`64bits addr += 32bits y1 * 32bits pitch`.
Another reason is that using `unsined int offset` to store the
calculation result of negative x1 and y1, offset may be a very big
number because of overflow of `negative int`.
Do you agree with that?
Regards,
Jason-JH.Lin
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
> MK1 1PT, UK
> Registration No: 1397386 (Wales)
>
Powered by blists - more mailing lists