All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Hongling Zeng" <zenghongling@kylinos.cn>
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	simona@ffwll.ch, airlied@redhat.com, bskeggs@nvidia.com,
	dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, zhongling0719@126.com
Subject: Re: [PATCH] nouveau/gsp: fix NULL pointer dereference in r535 nvenc/ofs alloc
Date: Tue, 26 May 2026 15:16:54 +0200	[thread overview]
Message-ID: <DISMY2BS8E1D.Q85V8DKCPM1C@kernel.org> (raw)
In-Reply-To: <20260526014721.13299-1-zenghongling@kylinos.cn>

On Tue May 26, 2026 at 3:47 AM CEST, Hongling Zeng wrote:
> nvkm_gsp_rm_alloc_get() can return NULL as well as error pointers.
> The current code only checks for error pointers with IS_ERR(), which
> would lead to a NULL pointer dereference if NULL is returned.
>
> Fix by using IS_ERR_OR_NULL() instead of IS_ERR(), matching the
> pattern used in nvkm_gsp_rm_alloc().

There was a similar patch [1] a while ago for another callsite. I replied:

	Are we sure that this can ever return NULL in the first place? I know
	that nvkm_gsp_rm_alloc_get() internally checks for IS_ERR_OR_NULL(), but
	I couldn't find anything within the callchain that would actually return
	NULL.
	
	That said, I think IS_ERR_OR_NULL() checks are misleading.

Is there a real case where NULL can be returned? If not, let's remove the
IS_ERR_OR_NULL() throughout the whole chain instead.

[1] https://lore.kernel.org/lkml/20260418071412.86022-1-sunliming@linux.dev/

WARNING: multiple messages have this Message-ID (diff)
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Hongling Zeng" <zenghongling@kylinos.cn>
Cc: <lyude@redhat.com>, <maarten.lankhorst@linux.intel.com>,
	<mripard@kernel.org>, <tzimmermann@suse.de>, <airlied@gmail.com>,
	<simona@ffwll.ch>, <airlied@redhat.com>, <ttabi@nvidia.com>,
	<bskeggs@nvidia.com>, <dri-devel@lists.freedesktop.org>,
	<nouveau@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
	<zhongling0719@126.com>
Subject: Re: [PATCH] nouveau/gsp: fix NULL pointer dereference in r535 nvenc/ofs alloc
Date: Tue, 26 May 2026 15:16:54 +0200	[thread overview]
Message-ID: <DISMY2BS8E1D.Q85V8DKCPM1C@kernel.org> (raw)
In-Reply-To: <20260526014721.13299-1-zenghongling@kylinos.cn>

On Tue May 26, 2026 at 3:47 AM CEST, Hongling Zeng wrote:
> nvkm_gsp_rm_alloc_get() can return NULL as well as error pointers.
> The current code only checks for error pointers with IS_ERR(), which
> would lead to a NULL pointer dereference if NULL is returned.
>
> Fix by using IS_ERR_OR_NULL() instead of IS_ERR(), matching the
> pattern used in nvkm_gsp_rm_alloc().

There was a similar patch [1] a while ago for another callsite. I replied:

	Are we sure that this can ever return NULL in the first place? I know
	that nvkm_gsp_rm_alloc_get() internally checks for IS_ERR_OR_NULL(), but
	I couldn't find anything within the callchain that would actually return
	NULL.
	
	That said, I think IS_ERR_OR_NULL() checks are misleading.

Is there a real case where NULL can be returned? If not, let's remove the
IS_ERR_OR_NULL() throughout the whole chain instead.

[1] https://lore.kernel.org/lkml/20260418071412.86022-1-sunliming@linux.dev/

  reply	other threads:[~2026-05-26 13:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26  1:47 [PATCH] nouveau/gsp: fix NULL pointer dereference in r535 nvenc/ofs alloc Hongling Zeng
2026-05-26 13:16 ` Danilo Krummrich [this message]
2026-05-26 13:16   ` Danilo Krummrich
2026-05-27  1:56   ` Hongling Zeng
2026-05-27  1:56     ` Hongling Zeng
2026-05-27 10:39     ` Danilo Krummrich
2026-05-27 10:39       ` Danilo Krummrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DISMY2BS8E1D.Q85V8DKCPM1C@kernel.org \
    --to=dakr@kernel.org \
    --cc=airlied@redhat.com \
    --cc=bskeggs@nvidia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=simona@ffwll.ch \
    --cc=zenghongling@kylinos.cn \
    --cc=zhongling0719@126.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.