Re: [PATCH v3] drm/panthor: Fix couple of NULL vs IS_ERR() bugs

[Dan Carpenter]

On Tue, Apr 02, 2024 at 05:19:25PM +0200, Boris Brezillon wrote:
> On Tue, 2 Apr 2024 17:44:18 +0300
> Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
> 
> > On Tue, Apr 02, 2024 at 04:38:38PM +0200, Boris Brezillon wrote:
> > > On Tue,  2 Apr 2024 07:14:11 -0700
> > > Harshit Mogalapalli <harshit.m.mogalapalli@xxxxxxxxxx> wrote:
> > >   
> > > > Currently panthor_vm_get_heap_pool() returns both ERR_PTR() and
> > > > NULL(when create is false and if there is no poool attached to the  
> > > 
> > >                                                ^ pool
> > >   
> > > > VM)
> > > > 	- Change the function to return error pointers, when pool is
> > > > 	  NULL return -ENOENT
> > > > 	- Also handle the callers to check for IS_ERR() on failure.
> > > > 
> > > > Fixes: 4bdca1150792 ("drm/panthor: Add the driver frontend block")  
> > > 
> > > I would explain that the code was correct, but the documentation didn't
> > > match the function behavior, otherwise it feels a bit weird to have a
> > > Fixes tag here.  
> > 
> > The code wasn't correct, it returned a mix of error pointers and NULL.
> 
> AFAICT, this is allowed, otherwise why would we have IS_ERR_OR_NULL().

Yep.  I have written a blog about this:
https://staticthinking.wordpress.com/2022/08/01/mixing-error-pointers-and-null/

> The fact smatch can't see through panthor_vm_get_heap_pool() and detect
> that the return value is different for create=false/true doesn't mean
> the code was wrong. I'm certainly not saying this is a good thing to
> have a function that encodes the error case with two different kind of
> return value, but I wouldn't qualify it as a bug either. What's
> incorrect though, is the fact the documentation doesn't match the code.
> 
> > So it needs a Fixes tag.
> 
> I didn't say we should drop the Fixes tag, but the bug being fixed here
> is a mismatch between the doc and the implementation, the code itself
> was correct, and the behavior is actually unchanged with this patch
> applied, it's just done in a less confusing way.

Oh.  Sorry, I haven't been following this thread closely and I misread
the code as well.  You're right that the code works.  In this case, I
would say actually that it does not need a Fixes tag because it's not
a bug.  It's just a cleanup.

Sorry for the noise.

regards,
dan carpenter