[PATCH v3 3/4] drm/mediatek: Add casting before assign

[Jason-JH Lin (林睿祥)]

An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230718/6139b59c/attachment-0001.htm>
-------------- next part --------------
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)
>