[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240402171925.41dce3a5@collabora.com>
Date: Tue, 2 Apr 2024 17:19:25 +0200
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>, Steven Price
<steven.price@....com>, Liviu Dudau <liviu.dudau@....com>, Maarten
Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
<mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie
<airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>, Heiko Stuebner
<heiko@...ech.de>, Grant Likely <grant.likely@...aro.org>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
kernel-janitors@...r.kernel.org, error27@...il.com
Subject: Re: [PATCH v3] drm/panthor: Fix couple of NULL vs IS_ERR() bugs
On Tue, 2 Apr 2024 17:44:18 +0300
Dan Carpenter <dan.carpenter@...aro.org> 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@...cle.com> 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().
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.
Regards,
Boris
Powered by blists - more mailing lists