<pre>
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)
>

</pre><!--type:text--><!--{--><pre>************* MEDIATEK Confidentiality Notice ********************
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
</pre><!--}-->