Nouveau - Sep 2023 - [PATCH] nouveau/u_memcpya: fix NULL vs error pointer bug

On Sat, Sep 16, 2023 at 01:41:43AM +0200, Danilo Krummrich
wrote:
> Hi Dan,
> 
> On 9/15/23 14:59, Dan Carpenter wrote:
> > The u_memcpya() function is supposed to return error pointers on
> > error.  Returning NULL will lead to an Oops.
> > 
> > Fixes: 68132cc6d1bc ("nouveau/u_memcpya: use vmemdup_user")
> > Signed-off-by: Dan Carpenter <dan.carpenter at linaro.org>
> > ---
> >   drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
> > index 3666a7403e47..52a708a98915 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> > @@ -193,7 +193,7 @@ u_memcpya(uint64_t user, unsigned int nmemb,
unsigned int size)
> >   	size_t bytes;
> >   	if (unlikely(check_mul_overflow(nmemb, size, &bytes)))
> > -		return NULL;
> > +		return ERR_PTR(-ENOMEM);
> 
> I plan to replace this function with an upcoming vmemdup_array_user()
helper,
> which returns -EOVERFLOW instead, hence mind using that?
> 
> Unless you disagree, no need to resubmit the patch, I can change it
> before applying the patch.
Generally, I would say that ENOMEM is the correct error code.  I feel
like someone thinks EOVERFLOW means integer overflow and that's not
correct.  I means like if you pass a number higher than INT_MAX to
kstroint().

But I don't care strongly about this.  You can change it if you want to.

regards,
dan carpenter

On Sat, Sep 16, 2023 at 05:24:04PM +0300, Dan Carpenter
wrote:
> On Sat, Sep 16, 2023 at 01:41:43AM +0200, Danilo Krummrich wrote:
> > Hi Dan,
> > 
> > On 9/15/23 14:59, Dan Carpenter wrote:
> > > The u_memcpya() function is supposed to return error pointers on
> > > error.  Returning NULL will lead to an Oops.
> > > 
> > > Fixes: 68132cc6d1bc ("nouveau/u_memcpya: use
vmemdup_user")
> > > Signed-off-by: Dan Carpenter <dan.carpenter at linaro.org>
> > > ---
> > >   drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
> > > index 3666a7403e47..52a708a98915 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> > > @@ -193,7 +193,7 @@ u_memcpya(uint64_t user, unsigned int nmemb,
unsigned int size)
> > >   	size_t bytes;
> > >   	if (unlikely(check_mul_overflow(nmemb, size, &bytes)))
> > > -		return NULL;
> > > +		return ERR_PTR(-ENOMEM);
> > 
> > I plan to replace this function with an upcoming vmemdup_array_user()
helper,
> > which returns -EOVERFLOW instead, hence mind using that?
> > 
> > Unless you disagree, no need to resubmit the patch, I can change it
> > before applying the patch.
> 
> Generally, I would say that ENOMEM is the correct error code.  I feel
> like someone thinks EOVERFLOW means integer overflow and that's not
> correct.  I means like if you pass a number higher than INT_MAX to
> kstroint().
The most common error code for integer overflows is EINVAL because the
user passed invalid data.

regards,
dan carpenter

On 9/16/23 16:24, Dan Carpenter wrote:
> On Sat, Sep 16, 2023 at 01:41:43AM +0200, Danilo Krummrich wrote:
>> Hi Dan,
>>
>> On 9/15/23 14:59, Dan Carpenter wrote:
>>> The u_memcpya() function is supposed to return error pointers on
>>> error.  Returning NULL will lead to an Oops.
>>>
>>> Fixes: 68132cc6d1bc ("nouveau/u_memcpya: use
vmemdup_user")
>>> Signed-off-by: Dan Carpenter <dan.carpenter at linaro.org>
>>> ---
>>>    drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
>>> index 3666a7403e47..52a708a98915 100644
>>> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
>>> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
>>> @@ -193,7 +193,7 @@ u_memcpya(uint64_t user, unsigned int nmemb,
unsigned int size)
>>>    	size_t bytes;
>>>    	if (unlikely(check_mul_overflow(nmemb, size, &bytes)))
>>> -		return NULL;
>>> +		return ERR_PTR(-ENOMEM);
>>
>> I plan to replace this function with an upcoming vmemdup_array_user()
helper,
>> which returns -EOVERFLOW instead, hence mind using that?
>>
>> Unless you disagree, no need to resubmit the patch, I can change it
>> before applying the patch.
> 
> Generally, I would say that ENOMEM is the correct error code.  I feel
> like someone thinks EOVERFLOW means integer overflow and that's not
> correct.  I means like if you pass a number higher than INT_MAX to
> kstroint().
> 
> But I don't care strongly about this.  You can change it if you want
to.
I seems that vmemdup_array_user() will keep using EOVERFLOW, hence aligning to
that.

Pushed the patch to drm-misc-fixes, thanks!
> 
> regards,
> dan carpenter
>