* [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
@ 2026-05-28 6:24 Hongling Zeng
2026-05-28 6:24 ` [PATCH 1/5] nouveau/gsp: cleanup IS_ERR_OR_NULL in rm_alloc functions Hongling Zeng
` (5 more replies)
0 siblings, 6 replies; 21+ messages in thread
From: Hongling Zeng @ 2026-05-28 6:24 UTC (permalink / raw)
To: lyude, dakr, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, airlied, ttabi, bskeggs, dri-devel
Cc: nouveau, linux-kernel, zhongling0719, Hongling Zeng
This patch series cleans up redundant IS_ERR_OR_NULL() checks in the
nouveau GSP-RM code.
The core GSP-RM functions already return error pointers via IS_ERR()
checks. Using IS_ERR_OR_NULL() is redundant and adds unnecessary NULL
checks.
This series is organized as follows:
- Patch 1: Cleanup IS_ERR_OR_NULL in nvkm_gsp_rm_alloc_get/alloc
- Patch 2: Cleanup IS_ERR_OR_NULL in nvkm_gsp_rpc_rd
- Patch 3: Cleanup IS_ERR_OR_NULL in core implementation
- Patch 4: Cleanup WARN_ON(IS_ERR_OR_NULL) across multiple files
- Patch 5: Cleanup remaining IS_ERR_OR_NULL usage
After this cleanup:
- Error handling is consistent with the rest of the kernel
- Code is simpler and more maintainable
- The intent is clearer (checking for error pointers, not NULL)
Hongling Zeng (5):
nouveau/gsp: cleanup IS_ERR_OR_NULL in rm_alloc functions
nouveau/gsp: cleanup IS_ERR_OR_NULL in rpc_rd
nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation
nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL)
nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage
drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 4 ++--
.../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c | 4 ++--
.../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/bar.c | 2 +-
.../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/ctrl.c | 2 +-
.../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/nvenc.c | 2 +-
.../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/ofa.c | 2 +-
.../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c | 8 ++++----
7 files changed, 14 insertions(+), 14 deletions(-)
--
2.25.1
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH 1/5] nouveau/gsp: cleanup IS_ERR_OR_NULL in rm_alloc functions
2026-05-28 6:24 [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage Hongling Zeng
@ 2026-05-28 6:24 ` Hongling Zeng
2026-05-28 6:24 ` [PATCH 2/5] nouveau/gsp: cleanup IS_ERR_OR_NULL in rpc_rd Hongling Zeng
` (4 subsequent siblings)
5 siblings, 0 replies; 21+ messages in thread
From: Hongling Zeng @ 2026-05-28 6:24 UTC (permalink / raw)
To: lyude, dakr, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, airlied, ttabi, bskeggs, dri-devel
Cc: nouveau, linux-kernel, zhongling0719, Hongling Zeng
The underlying functions already return error pointers, so checking for
NULL with IS_ERR_OR_NULL() is redundant. Use IS_ERR() instead.
This affects:
- nvkm_gsp_rm_alloc_get()
- nvkm_gsp_rm_alloc()
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
index 64fed208e4cf..ab2bd88eebce 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
@@ -373,7 +373,7 @@ nvkm_gsp_rm_alloc_get(struct nvkm_gsp_object *parent, u32 handle, u32 oclass, u3
object->handle = handle;
argv = gsp->rm->api->alloc->get(object, oclass, argc);
- if (IS_ERR_OR_NULL(argv)) {
+ if (IS_ERR(argv)) {
object->client = NULL;
return argv;
}
@@ -415,8 +415,8 @@ nvkm_gsp_rm_alloc(struct nvkm_gsp_object *parent, u32 handle, u32 oclass, u32 ar
{
void *argv = nvkm_gsp_rm_alloc_get(parent, handle, oclass, argc, object);
- if (IS_ERR_OR_NULL(argv))
- return argv ? PTR_ERR(argv) : -EIO;
+ if (IS_ERR(argv))
+ return PTR_ERR(argv);
return nvkm_gsp_rm_alloc_wr(object, argv);
}
--
2.25.1
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH 2/5] nouveau/gsp: cleanup IS_ERR_OR_NULL in rpc_rd
2026-05-28 6:24 [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage Hongling Zeng
2026-05-28 6:24 ` [PATCH 1/5] nouveau/gsp: cleanup IS_ERR_OR_NULL in rm_alloc functions Hongling Zeng
@ 2026-05-28 6:24 ` Hongling Zeng
2026-05-28 6:24 ` [PATCH 3/5] nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation Hongling Zeng
` (3 subsequent siblings)
5 siblings, 0 replies; 21+ messages in thread
From: Hongling Zeng @ 2026-05-28 6:24 UTC (permalink / raw)
To: lyude, dakr, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, airlied, ttabi, bskeggs, dri-devel
Cc: nouveau, linux-kernel, zhongling0719, Hongling Zeng
The underlying nvkm_gsp_rpc_get() function returns error pointers,
so checking for NULL with IS_ERR_OR_NULL() is redundant. Use IS_ERR()
instead.
This affects nvkm_gsp_rpc_rd().
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
index ab2bd88eebce..d771134fa410 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
@@ -293,7 +293,7 @@ nvkm_gsp_rpc_rd(struct nvkm_gsp *gsp, u32 fn, u32 argc)
{
void *argv = nvkm_gsp_rpc_get(gsp, fn, argc);
- if (IS_ERR_OR_NULL(argv))
+ if (IS_ERR(argv))
return argv;
return nvkm_gsp_rpc_push(gsp, argv, NVKM_GSP_RPC_REPLY_RECV, argc);
--
2.25.1
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH 3/5] nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation
2026-05-28 6:24 [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage Hongling Zeng
2026-05-28 6:24 ` [PATCH 1/5] nouveau/gsp: cleanup IS_ERR_OR_NULL in rm_alloc functions Hongling Zeng
2026-05-28 6:24 ` [PATCH 2/5] nouveau/gsp: cleanup IS_ERR_OR_NULL in rpc_rd Hongling Zeng
@ 2026-05-28 6:24 ` Hongling Zeng
2026-05-28 6:24 ` [PATCH 4/5] nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL) Hongling Zeng
` (2 subsequent siblings)
5 siblings, 0 replies; 21+ messages in thread
From: Hongling Zeng @ 2026-05-28 6:24 UTC (permalink / raw)
To: lyude, dakr, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, airlied, ttabi, bskeggs, dri-devel
Cc: nouveau, linux-kernel, zhongling0719, Hongling Zeng
Clean up IS_ERR_OR_NULL() checks in the core RPC and alloc
implementation files. The underlying functions return error pointers,
so IS_ERR() is sufficient.
This affects:
- r535_gsp_rpc_rm_free() in alloc.c
- r535_gsp_rpc_rm_alloc_push() in alloc.c
- r535_gsp_msgq_recv() in rpc.c
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c | 4 ++--
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c
index 46e3a29f2ad7..27f275d2e151 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c
@@ -35,7 +35,7 @@ r535_gsp_rpc_rm_free(struct nvkm_gsp_object *object)
client->object.handle, object->handle);
rpc = nvkm_gsp_rpc_get(gsp, NV_VGPU_MSG_FUNCTION_FREE, sizeof(*rpc));
- if (WARN_ON(IS_ERR_OR_NULL(rpc)))
+ if (WARN_ON(IS_ERR(rpc)))
return -EIO;
rpc->params.hRoot = client->object.handle;
@@ -60,7 +60,7 @@ r535_gsp_rpc_rm_alloc_push(struct nvkm_gsp_object *object, void *params)
void *ret = NULL;
rpc = nvkm_gsp_rpc_push(gsp, rpc, NVKM_GSP_RPC_REPLY_RECV, sizeof(*rpc));
- if (IS_ERR_OR_NULL(rpc))
+ if (IS_ERR(rpc))
return rpc;
if (rpc->status) {
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c
index 3ca3de8f4340..41301f19729c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c
@@ -324,7 +324,7 @@ r535_gsp_msgq_recv(struct nvkm_gsp *gsp, u32 gsp_rpc_len, int *retries)
u32 size;
rpc = r535_gsp_msgq_peek(gsp, sizeof(*rpc), info.retries);
- if (IS_ERR_OR_NULL(rpc)) {
+ if (IS_ERR(rpc)) {
kvfree(buf);
return rpc;
}
@@ -333,7 +333,7 @@ r535_gsp_msgq_recv(struct nvkm_gsp *gsp, u32 gsp_rpc_len, int *retries)
info.continuation = true;
rpc = r535_gsp_msgq_recv_one_elem(gsp, &info);
- if (IS_ERR_OR_NULL(rpc)) {
+ if (IS_ERR(rpc)) {
kvfree(buf);
return rpc;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH 4/5] nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL)
2026-05-28 6:24 [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage Hongling Zeng
` (2 preceding siblings ...)
2026-05-28 6:24 ` [PATCH 3/5] nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation Hongling Zeng
@ 2026-05-28 6:24 ` Hongling Zeng
2026-05-28 6:24 ` [PATCH 5/5] nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage Hongling Zeng
2026-05-28 16:41 ` [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage lyude
5 siblings, 0 replies; 21+ messages in thread
From: Hongling Zeng @ 2026-05-28 6:24 UTC (permalink / raw)
To: lyude, dakr, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, airlied, ttabi, bskeggs, dri-devel
Cc: nouveau, linux-kernel, zhongling0719, Hongling Zeng
Replace WARN_ON(IS_ERR_OR_NULL()) with WARN_ON(IS_ERR()) in various
GSP-RM files. The underlying functions return error pointers, so
checking for NULL is redundant.
This affects:
- r535_bar_bar2_update_pde() in bar.c
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/bar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/bar.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/bar.c
index fae08ac3b18c..9cd68f8622d3 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/bar.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/bar.c
@@ -55,7 +55,7 @@ r535_bar_bar2_update_pde(struct nvkm_gsp *gsp, u8 page_shift, u64 pdbe)
rpc_update_bar_pde_v15_00 *rpc;
rpc = nvkm_gsp_rpc_get(gsp, NV_VGPU_MSG_FUNCTION_UPDATE_BAR_PDE, sizeof(*rpc));
- if (WARN_ON(IS_ERR_OR_NULL(rpc)))
+ if (WARN_ON(IS_ERR(rpc)))
return -EIO;
rpc->info.barType = NV_RPC_UPDATE_PDE_BAR_2;
--
2.25.1
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH 5/5] nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage
2026-05-28 6:24 [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage Hongling Zeng
` (3 preceding siblings ...)
2026-05-28 6:24 ` [PATCH 4/5] nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL) Hongling Zeng
@ 2026-05-28 6:24 ` Hongling Zeng
2026-05-28 16:41 ` [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage lyude
5 siblings, 0 replies; 21+ messages in thread
From: Hongling Zeng @ 2026-05-28 6:24 UTC (permalink / raw)
To: lyude, dakr, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, airlied, ttabi, bskeggs, dri-devel
Cc: nouveau, linux-kernel, zhongling0719, Hongling Zeng
Clean up the remaining IS_ERR_OR_NULL() checks in ctrl.c and rpc.c.
The underlying functions return error pointers, so IS_ERR() is
sufficient.
This affects:
- r535_gsp_rpc_ctrl() in ctrl.c
- r535_gsp_rpc_ctor() in rpc.c
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/ctrl.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/ctrl.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/ctrl.c
index 70b9ee911c5e..aa0ebd3dfb17 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/ctrl.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/ctrl.c
@@ -42,7 +42,7 @@ r535_gsp_rpc_rm_ctrl_push(struct nvkm_gsp_object *object, void **params, u32 rep
int ret = 0;
rpc = nvkm_gsp_rpc_push(gsp, rpc, NVKM_GSP_RPC_REPLY_RECV, repc);
- if (IS_ERR_OR_NULL(rpc)) {
+ if (IS_ERR(rpc)) {
*params = NULL;
return PTR_ERR(rpc);
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c
index 41301f19729c..0c9657cb2dd7 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c
@@ -459,11 +459,11 @@ r535_gsp_msg_recv(struct nvkm_gsp *gsp, int fn, u32 gsp_rpc_len)
retry:
rpc = r535_gsp_msgq_peek(gsp, sizeof(*rpc), &retries);
- if (IS_ERR_OR_NULL(rpc))
+ if (IS_ERR(rpc))
return rpc;
rpc = r535_gsp_msgq_recv(gsp, gsp_rpc_len, &retries);
- if (IS_ERR_OR_NULL(rpc))
+ if (IS_ERR(rpc))
return rpc;
if (rpc->rpc_result) {
@@ -561,7 +561,7 @@ r535_gsp_rpc_handle_reply(struct nvkm_gsp *gsp, u32 fn,
break;
case NVKM_GSP_RPC_REPLY_RECV:
reply = r535_gsp_msg_recv(gsp, fn, gsp_rpc_len);
- if (!IS_ERR_OR_NULL(reply))
+ if (!IS_ERR(reply))
repv = reply->data;
else
repv = reply;
--
2.25.1
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
2026-05-28 6:24 [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage Hongling Zeng
` (4 preceding siblings ...)
2026-05-28 6:24 ` [PATCH 5/5] nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage Hongling Zeng
@ 2026-05-28 16:41 ` lyude
2026-05-28 17:56 ` Danilo Krummrich
5 siblings, 1 reply; 21+ messages in thread
From: lyude @ 2026-05-28 16:41 UTC (permalink / raw)
To: Hongling Zeng, dakr, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, airlied, ttabi, bskeggs, dri-devel
Cc: nouveau, linux-kernel, zhongling0719
Reviewed-by: Lyude Paul <lyude@redhat.com>
Will push them to drm-misc in just a moment
On Thu, 2026-05-28 at 14:24 +0800, Hongling Zeng wrote:
> This patch series cleans up redundant IS_ERR_OR_NULL() checks in the
> nouveau GSP-RM code.
>
> The core GSP-RM functions already return error pointers via IS_ERR()
> checks. Using IS_ERR_OR_NULL() is redundant and adds unnecessary NULL
> checks.
>
> This series is organized as follows:
> - Patch 1: Cleanup IS_ERR_OR_NULL in nvkm_gsp_rm_alloc_get/alloc
> - Patch 2: Cleanup IS_ERR_OR_NULL in nvkm_gsp_rpc_rd
> - Patch 3: Cleanup IS_ERR_OR_NULL in core implementation
> - Patch 4: Cleanup WARN_ON(IS_ERR_OR_NULL) across multiple files
> - Patch 5: Cleanup remaining IS_ERR_OR_NULL usage
>
> After this cleanup:
> - Error handling is consistent with the rest of the kernel
> - Code is simpler and more maintainable
> - The intent is clearer (checking for error pointers, not NULL)
>
> Hongling Zeng (5):
> nouveau/gsp: cleanup IS_ERR_OR_NULL in rm_alloc functions
> nouveau/gsp: cleanup IS_ERR_OR_NULL in rpc_rd
> nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation
> nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL)
> nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage
>
> drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 4 ++--
> .../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c | 4 ++--
> .../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/bar.c | 2 +-
> .../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/ctrl.c | 2 +-
> .../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/nvenc.c | 2 +-
> .../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/ofa.c | 2 +-
> .../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c | 8 ++++----
> 7 files changed, 14 insertions(+), 14 deletions(-)
>
> --
> 2.25.1
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
2026-05-28 16:41 ` [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage lyude
@ 2026-05-28 17:56 ` Danilo Krummrich
0 siblings, 0 replies; 21+ messages in thread
From: Danilo Krummrich @ 2026-05-28 17:56 UTC (permalink / raw)
To: lyude
Cc: Hongling Zeng, maarten.lankhorst, mripard, simona, airlied,
bskeggs, dri-devel, nouveau, linux-kernel, zhongling0719
On Thu May 28, 2026 at 6:41 PM CEST, lyude wrote:
> Will push them to drm-misc in just a moment
[...]
>> nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage
I think at least this patch has to be reverted, it causes the following oops
probing nouveau on my machine.
I can't currently look into this, but I think Sashiko [1] has a valid point on
this one.
[1] https://sashiko.dev/#/patchset/20260528062451.54107-1-zenghongling%40kylinos.cn
May 28 19:49:27 cassiopeiae kernel: BUG: kernel NULL pointer dereference, address: 000000000000002c
May 28 19:49:27 cassiopeiae kernel: #PF: supervisor read access in kernel mode
May 28 19:49:27 cassiopeiae kernel: #PF: error_code(0x0000) - not-present page
May 28 19:49:27 cassiopeiae kernel: PGD 0 P4D 0
May 28 19:49:27 cassiopeiae kernel: Oops: Oops: 0000 [#1] SMP NOPTI
May 28 19:49:27 cassiopeiae kernel: CPU: 12 UID: 0 PID: 475 Comm: (udev-worker) Not tainted 7.1.0-rc5+ #14 PREEMPT(lazy)
May 28 19:49:27 cassiopeiae kernel: Hardware name: ASUS System Product Name/TUF GAMING B850-E WIFI, BIOS 1627 02/05/2026
May 28 19:49:27 cassiopeiae kernel: RIP: 0010:r535_gsp_rpc_rm_ctrl_push+0x60/0x110 [nouveau]
May 28 19:49:27 cassiopeiae kernel: Code: 4c 8b 58 08 4c 89 f7 ba 02 00 00 00 89 e9 2e 2e 2e 41 ff d3 48 89 c6 48 3d 01 f0 ff ff 72 0b 48 c7 03 00 00 00 00 89>
May 28 19:49:27 cassiopeiae kernel: RSP: 0018:ffffd3b38178f250 EFLAGS: 00010213
May 28 19:49:27 cassiopeiae kernel: RAX: 0000000000000020 RBX: ffffd3b38178f2a0 RCX: 0000000000000000
May 28 19:49:27 cassiopeiae kernel: RDX: 0000000000000038 RSI: 0000000000000020 RDI: ffff8aa9db3339d8
May 28 19:49:27 cassiopeiae kernel: RBP: 0000000000000000 R08: ffffffffbe380560 R09: ffffffffc04c9300
May 28 19:49:27 cassiopeiae kernel: R10: 0000000000000100 R11: ffffffffbd66c070 R12: 0000000090f10000
May 28 19:49:27 cassiopeiae kernel: R13: 0000000000000000 R14: ffff8aa9db333000 R15: ffff8aa9e1c2d600
May 28 19:49:27 cassiopeiae kernel: FS: 00007fb0623dc1c0(0000) GS:ffff8ab15f8b9000(0000) knlGS:0000000000000000
May 28 19:49:27 cassiopeiae kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
May 28 19:49:27 cassiopeiae kernel: CR2: 000000000000002c CR3: 000000011efcc000 CR4: 0000000000f50ef0
May 28 19:49:27 cassiopeiae kernel: PKRU: 55555554
May 28 19:49:27 cassiopeiae kernel: Call Trace:
May 28 19:49:27 cassiopeiae kernel: <TASK>
May 28 19:49:27 cassiopeiae kernel: r535_mmu_vaspace_new+0x1f8/0x520 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nvkm_uvmm_new+0x1b7/0x210 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nvkm_ioctl_new+0x22d/0x340 [nouveau]
May 28 19:49:27 cassiopeiae kernel: ? nvkm_uvmm_search+0x30/0x30 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nvkm_ioctl+0xf7/0x1f0 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nvif_object_ctor+0x134/0x2b0 [nouveau]
May 28 19:49:27 cassiopeiae kernel: ? nvkm_uvmm_search+0x30/0x30 [nouveau]
May 28 19:49:27 cassiopeiae kernel: ? __kmalloc_noprof+0x205/0x550
May 28 19:49:27 cassiopeiae kernel: ? nvif_vmm_ctor+0x65/0x280 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nvif_vmm_ctor+0xe5/0x280 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nouveau_vmm_init+0x3b/0x50 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nouveau_cli_init+0x25f/0x450 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nouveau_drm_device_init+0x69/0x840 [nouveau]
May 28 19:49:27 cassiopeiae kernel: ? pci_bus_read_config_word+0x4b/0x80
May 28 19:49:27 cassiopeiae kernel: nouveau_drm_probe+0xc7/0x190 [nouveau]
May 28 19:49:27 cassiopeiae kernel: pci_device_probe+0x1f9/0x300
May 28 19:49:27 cassiopeiae kernel: really_probe+0x1b8/0x480
May 28 19:49:27 cassiopeiae kernel: __driver_probe_device+0x9d/0x130
May 28 19:49:27 cassiopeiae kernel: driver_probe_device+0x1e/0x100
May 28 19:49:27 cassiopeiae kernel: __driver_attach+0xab/0x210
May 28 19:49:27 cassiopeiae kernel: ? driver_attach+0x20/0x20
May 28 19:49:27 cassiopeiae kernel: bus_for_each_dev+0x10b/0x150
May 28 19:49:27 cassiopeiae kernel: bus_add_driver+0x184/0x2d0
May 28 19:49:27 cassiopeiae kernel: driver_register+0x61/0xf0
May 28 19:49:27 cassiopeiae kernel: init_module+0x1bd/0x1000 [nouveau]
May 28 19:49:27 cassiopeiae kernel: ? cleanup_module+0x2e0/0x2e0 [video]
May 28 19:49:27 cassiopeiae kernel: do_one_initcall+0x12e/0x350
May 28 19:49:27 cassiopeiae kernel: ? security_kernfs_init_security+0x58/0x130
May 28 19:49:27 cassiopeiae kernel: ? __kernfs_new_node+0x1be/0x270
May 28 19:49:27 cassiopeiae kernel: ? security_kernfs_init_security+0x58/0x130
May 28 19:49:27 cassiopeiae kernel: ? __add_to_free_list+0x98/0x170
May 28 19:49:27 cassiopeiae kernel: ? __free_one_page+0x34c/0x450
May 28 19:49:27 cassiopeiae kernel: ? free_pcppages_bulk+0x19d/0x270
May 28 19:49:27 cassiopeiae kernel: ? free_frozen_page_commit+0xaa/0x4b0
May 28 19:49:27 cassiopeiae kernel: ? __free_frozen_pages+0x29e/0x670
May 28 19:49:27 cassiopeiae kernel: ? load_module+0x1354/0x14e0
May 28 19:49:27 cassiopeiae kernel: ? __kmalloc_cache_noprof+0x189/0x420
May 28 19:49:27 cassiopeiae kernel: do_init_module+0x82/0x270
May 28 19:49:27 cassiopeiae kernel: __se_sys_finit_module+0x26a/0x3d0
May 28 19:49:27 cassiopeiae kernel: do_syscall_64+0x12a/0x3b0
May 28 19:49:27 cassiopeiae kernel: ? vfs_read+0x14d/0x300
May 28 19:49:27 cassiopeiae kernel: ? __x64_sys_pread64+0x70/0xc0
May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0x165/0x3b0
May 28 19:49:27 cassiopeiae kernel: ? do_sys_openat2+0x93/0xd0
May 28 19:49:27 cassiopeiae kernel: ? __x64_sys_openat+0x80/0xa0
May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0x165/0x3b0
May 28 19:49:27 cassiopeiae kernel: ? __x64_sys_pread64+0x70/0xc0
May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0x165/0x3b0
May 28 19:49:27 cassiopeiae kernel: ? do_user_addr_fault+0x273/0x6a0
May 28 19:49:27 cassiopeiae kernel: ? irqentry_exit+0x3f/0x630
May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0xe9/0x3b0
May 28 19:49:27 cassiopeiae kernel: entry_SYSCALL_64_after_hwframe+0x67/0x6f
May 28 19:49:27 cassiopeiae kernel: RIP: 0033:0x7fb062bb26bd
May 28 19:49:27 cassiopeiae kernel: Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24>
May 28 19:49:27 cassiopeiae kernel: RSP: 002b:00007ffe2bae4d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
May 28 19:49:27 cassiopeiae kernel: RAX: ffffffffffffffda RBX: 000055b4032b23e0 RCX: 00007fb062bb26bd
May 28 19:49:27 cassiopeiae kernel: RDX: 0000000000000000 RSI: 000055b403434900 RDI: 0000000000000043
May 28 19:49:27 cassiopeiae kernel: RBP: 00007ffe2bae4df0 R08: 0000000000000000 R09: 0000000000000000
May 28 19:49:27 cassiopeiae kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 000055b403434900
May 28 19:49:27 cassiopeiae kernel: R13: 000055b40340c570 R14: 0000000000020000 R15: 000055b403437260
May 28 19:49:27 cassiopeiae kernel: </TASK>
May 28 19:49:27 cassiopeiae kernel: Modules linked in: nouveau(+) drm_display_helper cec gpu_sched drm_gpuvm drm_exec drm_ttm_helper ttm nvme nvme_core nvme_k>
May 28 19:49:27 cassiopeiae kernel: CR2: 000000000000002c
May 28 19:49:27 cassiopeiae kernel: ---[ end trace 0000000000000000 ]---
May 28 19:49:27 cassiopeiae kernel: RIP: 0010:r535_gsp_rpc_rm_ctrl_push+0x60/0x110 [nouveau]
May 28 19:49:27 cassiopeiae kernel: Code: 4c 8b 58 08 4c 89 f7 ba 02 00 00 00 89 e9 2e 2e 2e 41 ff d3 48 89 c6 48 3d 01 f0 ff ff 72 0b 48 c7 03 00 00 00 00 89>
May 28 19:49:27 cassiopeiae kernel: RSP: 0018:ffffd3b38178f250 EFLAGS: 00010213
May 28 19:49:27 cassiopeiae kernel: RAX: 0000000000000020 RBX: ffffd3b38178f2a0 RCX: 0000000000000000
May 28 19:49:27 cassiopeiae kernel: RDX: 0000000000000038 RSI: 0000000000000020 RDI: ffff8aa9db3339d8
May 28 19:49:27 cassiopeiae kernel: RBP: 0000000000000000 R08: ffffffffbe380560 R09: ffffffffc04c9300
May 28 19:49:27 cassiopeiae kernel: R10: 0000000000000100 R11: ffffffffbd66c070 R12: 0000000090f10000
May 28 19:49:27 cassiopeiae kernel: R13: 0000000000000000 R14: ffff8aa9db333000 R15: ffff8aa9e1c2d600
May 28 19:49:27 cassiopeiae kernel: FS: 00007fb0623dc1c0(0000) GS:ffff8ab15f8b9000(0000) knlGS:0000000000000000
May 28 19:49:27 cassiopeiae kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
May 28 19:49:27 cassiopeiae kernel: CR2: 000000000000002c CR3: 000000011efcc000 CR4: 0000000000f50ef0
May 28 19:49:27 cassiopeiae kernel: PKRU: 55555554
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
@ 2026-05-28 17:56 ` Danilo Krummrich
0 siblings, 0 replies; 21+ messages in thread
From: Danilo Krummrich @ 2026-05-28 17:56 UTC (permalink / raw)
To: lyude
Cc: Hongling Zeng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, airlied, ttabi, bskeggs, dri-devel, nouveau, linux-kernel,
zhongling0719
On Thu May 28, 2026 at 6:41 PM CEST, lyude wrote:
> Will push them to drm-misc in just a moment
[...]
>> nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage
I think at least this patch has to be reverted, it causes the following oops
probing nouveau on my machine.
I can't currently look into this, but I think Sashiko [1] has a valid point on
this one.
[1] https://sashiko.dev/#/patchset/20260528062451.54107-1-zenghongling%40kylinos.cn
May 28 19:49:27 cassiopeiae kernel: BUG: kernel NULL pointer dereference, address: 000000000000002c
May 28 19:49:27 cassiopeiae kernel: #PF: supervisor read access in kernel mode
May 28 19:49:27 cassiopeiae kernel: #PF: error_code(0x0000) - not-present page
May 28 19:49:27 cassiopeiae kernel: PGD 0 P4D 0
May 28 19:49:27 cassiopeiae kernel: Oops: Oops: 0000 [#1] SMP NOPTI
May 28 19:49:27 cassiopeiae kernel: CPU: 12 UID: 0 PID: 475 Comm: (udev-worker) Not tainted 7.1.0-rc5+ #14 PREEMPT(lazy)
May 28 19:49:27 cassiopeiae kernel: Hardware name: ASUS System Product Name/TUF GAMING B850-E WIFI, BIOS 1627 02/05/2026
May 28 19:49:27 cassiopeiae kernel: RIP: 0010:r535_gsp_rpc_rm_ctrl_push+0x60/0x110 [nouveau]
May 28 19:49:27 cassiopeiae kernel: Code: 4c 8b 58 08 4c 89 f7 ba 02 00 00 00 89 e9 2e 2e 2e 41 ff d3 48 89 c6 48 3d 01 f0 ff ff 72 0b 48 c7 03 00 00 00 00 89>
May 28 19:49:27 cassiopeiae kernel: RSP: 0018:ffffd3b38178f250 EFLAGS: 00010213
May 28 19:49:27 cassiopeiae kernel: RAX: 0000000000000020 RBX: ffffd3b38178f2a0 RCX: 0000000000000000
May 28 19:49:27 cassiopeiae kernel: RDX: 0000000000000038 RSI: 0000000000000020 RDI: ffff8aa9db3339d8
May 28 19:49:27 cassiopeiae kernel: RBP: 0000000000000000 R08: ffffffffbe380560 R09: ffffffffc04c9300
May 28 19:49:27 cassiopeiae kernel: R10: 0000000000000100 R11: ffffffffbd66c070 R12: 0000000090f10000
May 28 19:49:27 cassiopeiae kernel: R13: 0000000000000000 R14: ffff8aa9db333000 R15: ffff8aa9e1c2d600
May 28 19:49:27 cassiopeiae kernel: FS: 00007fb0623dc1c0(0000) GS:ffff8ab15f8b9000(0000) knlGS:0000000000000000
May 28 19:49:27 cassiopeiae kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
May 28 19:49:27 cassiopeiae kernel: CR2: 000000000000002c CR3: 000000011efcc000 CR4: 0000000000f50ef0
May 28 19:49:27 cassiopeiae kernel: PKRU: 55555554
May 28 19:49:27 cassiopeiae kernel: Call Trace:
May 28 19:49:27 cassiopeiae kernel: <TASK>
May 28 19:49:27 cassiopeiae kernel: r535_mmu_vaspace_new+0x1f8/0x520 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nvkm_uvmm_new+0x1b7/0x210 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nvkm_ioctl_new+0x22d/0x340 [nouveau]
May 28 19:49:27 cassiopeiae kernel: ? nvkm_uvmm_search+0x30/0x30 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nvkm_ioctl+0xf7/0x1f0 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nvif_object_ctor+0x134/0x2b0 [nouveau]
May 28 19:49:27 cassiopeiae kernel: ? nvkm_uvmm_search+0x30/0x30 [nouveau]
May 28 19:49:27 cassiopeiae kernel: ? __kmalloc_noprof+0x205/0x550
May 28 19:49:27 cassiopeiae kernel: ? nvif_vmm_ctor+0x65/0x280 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nvif_vmm_ctor+0xe5/0x280 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nouveau_vmm_init+0x3b/0x50 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nouveau_cli_init+0x25f/0x450 [nouveau]
May 28 19:49:27 cassiopeiae kernel: nouveau_drm_device_init+0x69/0x840 [nouveau]
May 28 19:49:27 cassiopeiae kernel: ? pci_bus_read_config_word+0x4b/0x80
May 28 19:49:27 cassiopeiae kernel: nouveau_drm_probe+0xc7/0x190 [nouveau]
May 28 19:49:27 cassiopeiae kernel: pci_device_probe+0x1f9/0x300
May 28 19:49:27 cassiopeiae kernel: really_probe+0x1b8/0x480
May 28 19:49:27 cassiopeiae kernel: __driver_probe_device+0x9d/0x130
May 28 19:49:27 cassiopeiae kernel: driver_probe_device+0x1e/0x100
May 28 19:49:27 cassiopeiae kernel: __driver_attach+0xab/0x210
May 28 19:49:27 cassiopeiae kernel: ? driver_attach+0x20/0x20
May 28 19:49:27 cassiopeiae kernel: bus_for_each_dev+0x10b/0x150
May 28 19:49:27 cassiopeiae kernel: bus_add_driver+0x184/0x2d0
May 28 19:49:27 cassiopeiae kernel: driver_register+0x61/0xf0
May 28 19:49:27 cassiopeiae kernel: init_module+0x1bd/0x1000 [nouveau]
May 28 19:49:27 cassiopeiae kernel: ? cleanup_module+0x2e0/0x2e0 [video]
May 28 19:49:27 cassiopeiae kernel: do_one_initcall+0x12e/0x350
May 28 19:49:27 cassiopeiae kernel: ? security_kernfs_init_security+0x58/0x130
May 28 19:49:27 cassiopeiae kernel: ? __kernfs_new_node+0x1be/0x270
May 28 19:49:27 cassiopeiae kernel: ? security_kernfs_init_security+0x58/0x130
May 28 19:49:27 cassiopeiae kernel: ? __add_to_free_list+0x98/0x170
May 28 19:49:27 cassiopeiae kernel: ? __free_one_page+0x34c/0x450
May 28 19:49:27 cassiopeiae kernel: ? free_pcppages_bulk+0x19d/0x270
May 28 19:49:27 cassiopeiae kernel: ? free_frozen_page_commit+0xaa/0x4b0
May 28 19:49:27 cassiopeiae kernel: ? __free_frozen_pages+0x29e/0x670
May 28 19:49:27 cassiopeiae kernel: ? load_module+0x1354/0x14e0
May 28 19:49:27 cassiopeiae kernel: ? __kmalloc_cache_noprof+0x189/0x420
May 28 19:49:27 cassiopeiae kernel: do_init_module+0x82/0x270
May 28 19:49:27 cassiopeiae kernel: __se_sys_finit_module+0x26a/0x3d0
May 28 19:49:27 cassiopeiae kernel: do_syscall_64+0x12a/0x3b0
May 28 19:49:27 cassiopeiae kernel: ? vfs_read+0x14d/0x300
May 28 19:49:27 cassiopeiae kernel: ? __x64_sys_pread64+0x70/0xc0
May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0x165/0x3b0
May 28 19:49:27 cassiopeiae kernel: ? do_sys_openat2+0x93/0xd0
May 28 19:49:27 cassiopeiae kernel: ? __x64_sys_openat+0x80/0xa0
May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0x165/0x3b0
May 28 19:49:27 cassiopeiae kernel: ? __x64_sys_pread64+0x70/0xc0
May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0x165/0x3b0
May 28 19:49:27 cassiopeiae kernel: ? do_user_addr_fault+0x273/0x6a0
May 28 19:49:27 cassiopeiae kernel: ? irqentry_exit+0x3f/0x630
May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0xe9/0x3b0
May 28 19:49:27 cassiopeiae kernel: entry_SYSCALL_64_after_hwframe+0x67/0x6f
May 28 19:49:27 cassiopeiae kernel: RIP: 0033:0x7fb062bb26bd
May 28 19:49:27 cassiopeiae kernel: Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24>
May 28 19:49:27 cassiopeiae kernel: RSP: 002b:00007ffe2bae4d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
May 28 19:49:27 cassiopeiae kernel: RAX: ffffffffffffffda RBX: 000055b4032b23e0 RCX: 00007fb062bb26bd
May 28 19:49:27 cassiopeiae kernel: RDX: 0000000000000000 RSI: 000055b403434900 RDI: 0000000000000043
May 28 19:49:27 cassiopeiae kernel: RBP: 00007ffe2bae4df0 R08: 0000000000000000 R09: 0000000000000000
May 28 19:49:27 cassiopeiae kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 000055b403434900
May 28 19:49:27 cassiopeiae kernel: R13: 000055b40340c570 R14: 0000000000020000 R15: 000055b403437260
May 28 19:49:27 cassiopeiae kernel: </TASK>
May 28 19:49:27 cassiopeiae kernel: Modules linked in: nouveau(+) drm_display_helper cec gpu_sched drm_gpuvm drm_exec drm_ttm_helper ttm nvme nvme_core nvme_k>
May 28 19:49:27 cassiopeiae kernel: CR2: 000000000000002c
May 28 19:49:27 cassiopeiae kernel: ---[ end trace 0000000000000000 ]---
May 28 19:49:27 cassiopeiae kernel: RIP: 0010:r535_gsp_rpc_rm_ctrl_push+0x60/0x110 [nouveau]
May 28 19:49:27 cassiopeiae kernel: Code: 4c 8b 58 08 4c 89 f7 ba 02 00 00 00 89 e9 2e 2e 2e 41 ff d3 48 89 c6 48 3d 01 f0 ff ff 72 0b 48 c7 03 00 00 00 00 89>
May 28 19:49:27 cassiopeiae kernel: RSP: 0018:ffffd3b38178f250 EFLAGS: 00010213
May 28 19:49:27 cassiopeiae kernel: RAX: 0000000000000020 RBX: ffffd3b38178f2a0 RCX: 0000000000000000
May 28 19:49:27 cassiopeiae kernel: RDX: 0000000000000038 RSI: 0000000000000020 RDI: ffff8aa9db3339d8
May 28 19:49:27 cassiopeiae kernel: RBP: 0000000000000000 R08: ffffffffbe380560 R09: ffffffffc04c9300
May 28 19:49:27 cassiopeiae kernel: R10: 0000000000000100 R11: ffffffffbd66c070 R12: 0000000090f10000
May 28 19:49:27 cassiopeiae kernel: R13: 0000000000000000 R14: ffff8aa9db333000 R15: ffff8aa9e1c2d600
May 28 19:49:27 cassiopeiae kernel: FS: 00007fb0623dc1c0(0000) GS:ffff8ab15f8b9000(0000) knlGS:0000000000000000
May 28 19:49:27 cassiopeiae kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
May 28 19:49:27 cassiopeiae kernel: CR2: 000000000000002c CR3: 000000011efcc000 CR4: 0000000000f50ef0
May 28 19:49:27 cassiopeiae kernel: PKRU: 55555554
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
2026-05-28 17:56 ` Danilo Krummrich
@ 2026-05-28 18:21 ` lyude
-1 siblings, 0 replies; 21+ messages in thread
From: lyude @ 2026-05-28 18:21 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Hongling Zeng, maarten.lankhorst, mripard, simona, airlied,
bskeggs, dri-devel, nouveau, linux-kernel, zhongling0719
Oh dear, thank you for catching this.
Would you mind sending a revert and I can give an R-B and push it?
On Thu, 2026-05-28 at 19:56 +0200, Danilo Krummrich wrote:
> On Thu May 28, 2026 at 6:41 PM CEST, lyude wrote:
> > Will push them to drm-misc in just a moment
>
> [...]
>
> > > nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage
>
> I think at least this patch has to be reverted, it causes the
> following oops
> probing nouveau on my machine.
>
> I can't currently look into this, but I think Sashiko [1] has a valid
> point on
> this one.
>
> [1]
> https://sashiko.dev/#/patchset/20260528062451.54107-1-zenghongling%40kylinos.cn
>
> May 28 19:49:27 cassiopeiae kernel: BUG: kernel NULL pointer
> dereference, address: 000000000000002c
> May 28 19:49:27 cassiopeiae kernel: #PF: supervisor read access in
> kernel mode
> May 28 19:49:27 cassiopeiae kernel: #PF: error_code(0x0000) - not-
> present page
> May 28 19:49:27 cassiopeiae kernel: PGD 0 P4D 0
> May 28 19:49:27 cassiopeiae kernel: Oops: Oops: 0000 [#1] SMP NOPTI
> May 28 19:49:27 cassiopeiae kernel: CPU: 12 UID: 0 PID: 475 Comm:
> (udev-worker) Not tainted 7.1.0-rc5+ #14 PREEMPT(lazy)
> May 28 19:49:27 cassiopeiae kernel: Hardware name: ASUS System
> Product Name/TUF GAMING B850-E WIFI, BIOS 1627 02/05/2026
> May 28 19:49:27 cassiopeiae kernel: RIP:
> 0010:r535_gsp_rpc_rm_ctrl_push+0x60/0x110 [nouveau]
> May 28 19:49:27 cassiopeiae kernel: Code: 4c 8b 58 08 4c 89 f7 ba 02
> 00 00 00 89 e9 2e 2e 2e 41 ff d3 48 89 c6 48 3d 01 f0 ff ff 72 0b 48
> c7 03 00 00 00 00 89>
> May 28 19:49:27 cassiopeiae kernel: RSP: 0018:ffffd3b38178f250
> EFLAGS: 00010213
> May 28 19:49:27 cassiopeiae kernel: RAX: 0000000000000020 RBX:
> ffffd3b38178f2a0 RCX: 0000000000000000
> May 28 19:49:27 cassiopeiae kernel: RDX: 0000000000000038 RSI:
> 0000000000000020 RDI: ffff8aa9db3339d8
> May 28 19:49:27 cassiopeiae kernel: RBP: 0000000000000000 R08:
> ffffffffbe380560 R09: ffffffffc04c9300
> May 28 19:49:27 cassiopeiae kernel: R10: 0000000000000100 R11:
> ffffffffbd66c070 R12: 0000000090f10000
> May 28 19:49:27 cassiopeiae kernel: R13: 0000000000000000 R14:
> ffff8aa9db333000 R15: ffff8aa9e1c2d600
> May 28 19:49:27 cassiopeiae kernel: FS: 00007fb0623dc1c0(0000)
> GS:ffff8ab15f8b9000(0000) knlGS:0000000000000000
> May 28 19:49:27 cassiopeiae kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033
> May 28 19:49:27 cassiopeiae kernel: CR2: 000000000000002c CR3:
> 000000011efcc000 CR4: 0000000000f50ef0
> May 28 19:49:27 cassiopeiae kernel: PKRU: 55555554
> May 28 19:49:27 cassiopeiae kernel: Call Trace:
> May 28 19:49:27 cassiopeiae kernel: <TASK>
> May 28 19:49:27 cassiopeiae kernel: r535_mmu_vaspace_new+0x1f8/0x520
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nvkm_uvmm_new+0x1b7/0x210
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nvkm_ioctl_new+0x22d/0x340
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: ? nvkm_uvmm_search+0x30/0x30
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nvkm_ioctl+0xf7/0x1f0 [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nvif_object_ctor+0x134/0x2b0
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: ? nvkm_uvmm_search+0x30/0x30
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: ? __kmalloc_noprof+0x205/0x550
> May 28 19:49:27 cassiopeiae kernel: ? nvif_vmm_ctor+0x65/0x280
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nvif_vmm_ctor+0xe5/0x280
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nouveau_vmm_init+0x3b/0x50
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nouveau_cli_init+0x25f/0x450
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel:
> nouveau_drm_device_init+0x69/0x840 [nouveau]
> May 28 19:49:27 cassiopeiae kernel: ?
> pci_bus_read_config_word+0x4b/0x80
> May 28 19:49:27 cassiopeiae kernel: nouveau_drm_probe+0xc7/0x190
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: pci_device_probe+0x1f9/0x300
> May 28 19:49:27 cassiopeiae kernel: really_probe+0x1b8/0x480
> May 28 19:49:27 cassiopeiae kernel: __driver_probe_device+0x9d/0x130
> May 28 19:49:27 cassiopeiae kernel: driver_probe_device+0x1e/0x100
> May 28 19:49:27 cassiopeiae kernel: __driver_attach+0xab/0x210
> May 28 19:49:27 cassiopeiae kernel: ? driver_attach+0x20/0x20
> May 28 19:49:27 cassiopeiae kernel: bus_for_each_dev+0x10b/0x150
> May 28 19:49:27 cassiopeiae kernel: bus_add_driver+0x184/0x2d0
> May 28 19:49:27 cassiopeiae kernel: driver_register+0x61/0xf0
> May 28 19:49:27 cassiopeiae kernel: init_module+0x1bd/0x1000
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: ? cleanup_module+0x2e0/0x2e0
> [video]
> May 28 19:49:27 cassiopeiae kernel: do_one_initcall+0x12e/0x350
> May 28 19:49:27 cassiopeiae kernel: ?
> security_kernfs_init_security+0x58/0x130
> May 28 19:49:27 cassiopeiae kernel: ? __kernfs_new_node+0x1be/0x270
> May 28 19:49:27 cassiopeiae kernel: ?
> security_kernfs_init_security+0x58/0x130
> May 28 19:49:27 cassiopeiae kernel: ? __add_to_free_list+0x98/0x170
> May 28 19:49:27 cassiopeiae kernel: ? __free_one_page+0x34c/0x450
> May 28 19:49:27 cassiopeiae kernel: ? free_pcppages_bulk+0x19d/0x270
> May 28 19:49:27 cassiopeiae kernel: ?
> free_frozen_page_commit+0xaa/0x4b0
> May 28 19:49:27 cassiopeiae kernel: ?
> __free_frozen_pages+0x29e/0x670
> May 28 19:49:27 cassiopeiae kernel: ? load_module+0x1354/0x14e0
> May 28 19:49:27 cassiopeiae kernel: ?
> __kmalloc_cache_noprof+0x189/0x420
> May 28 19:49:27 cassiopeiae kernel: do_init_module+0x82/0x270
> May 28 19:49:27 cassiopeiae kernel:
> __se_sys_finit_module+0x26a/0x3d0
> May 28 19:49:27 cassiopeiae kernel: do_syscall_64+0x12a/0x3b0
> May 28 19:49:27 cassiopeiae kernel: ? vfs_read+0x14d/0x300
> May 28 19:49:27 cassiopeiae kernel: ? __x64_sys_pread64+0x70/0xc0
> May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0x165/0x3b0
> May 28 19:49:27 cassiopeiae kernel: ? do_sys_openat2+0x93/0xd0
> May 28 19:49:27 cassiopeiae kernel: ? __x64_sys_openat+0x80/0xa0
> May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0x165/0x3b0
> May 28 19:49:27 cassiopeiae kernel: ? __x64_sys_pread64+0x70/0xc0
> May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0x165/0x3b0
> May 28 19:49:27 cassiopeiae kernel: ? do_user_addr_fault+0x273/0x6a0
> May 28 19:49:27 cassiopeiae kernel: ? irqentry_exit+0x3f/0x630
> May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0xe9/0x3b0
> May 28 19:49:27 cassiopeiae kernel:
> entry_SYSCALL_64_after_hwframe+0x67/0x6f
> May 28 19:49:27 cassiopeiae kernel: RIP: 0033:0x7fb062bb26bd
> May 28 19:49:27 cassiopeiae kernel: Code: ff c3 66 2e 0f 1f 84 00 00
> 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2
> 4d 89 c8 4c 8b 4c 24>
> May 28 19:49:27 cassiopeiae kernel: RSP: 002b:00007ffe2bae4d58
> EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> May 28 19:49:27 cassiopeiae kernel: RAX: ffffffffffffffda RBX:
> 000055b4032b23e0 RCX: 00007fb062bb26bd
> May 28 19:49:27 cassiopeiae kernel: RDX: 0000000000000000 RSI:
> 000055b403434900 RDI: 0000000000000043
> May 28 19:49:27 cassiopeiae kernel: RBP: 00007ffe2bae4df0 R08:
> 0000000000000000 R09: 0000000000000000
> May 28 19:49:27 cassiopeiae kernel: R10: 0000000000000000 R11:
> 0000000000000246 R12: 000055b403434900
> May 28 19:49:27 cassiopeiae kernel: R13: 000055b40340c570 R14:
> 0000000000020000 R15: 000055b403437260
> May 28 19:49:27 cassiopeiae kernel: </TASK>
> May 28 19:49:27 cassiopeiae kernel: Modules linked in: nouveau(+)
> drm_display_helper cec gpu_sched drm_gpuvm drm_exec drm_ttm_helper
> ttm nvme nvme_core nvme_k>
> May 28 19:49:27 cassiopeiae kernel: CR2: 000000000000002c
> May 28 19:49:27 cassiopeiae kernel: ---[ end trace 0000000000000000
> ]---
> May 28 19:49:27 cassiopeiae kernel: RIP:
> 0010:r535_gsp_rpc_rm_ctrl_push+0x60/0x110 [nouveau]
> May 28 19:49:27 cassiopeiae kernel: Code: 4c 8b 58 08 4c 89 f7 ba 02
> 00 00 00 89 e9 2e 2e 2e 41 ff d3 48 89 c6 48 3d 01 f0 ff ff 72 0b 48
> c7 03 00 00 00 00 89>
> May 28 19:49:27 cassiopeiae kernel: RSP: 0018:ffffd3b38178f250
> EFLAGS: 00010213
> May 28 19:49:27 cassiopeiae kernel: RAX: 0000000000000020 RBX:
> ffffd3b38178f2a0 RCX: 0000000000000000
> May 28 19:49:27 cassiopeiae kernel: RDX: 0000000000000038 RSI:
> 0000000000000020 RDI: ffff8aa9db3339d8
> May 28 19:49:27 cassiopeiae kernel: RBP: 0000000000000000 R08:
> ffffffffbe380560 R09: ffffffffc04c9300
> May 28 19:49:27 cassiopeiae kernel: R10: 0000000000000100 R11:
> ffffffffbd66c070 R12: 0000000090f10000
> May 28 19:49:27 cassiopeiae kernel: R13: 0000000000000000 R14:
> ffff8aa9db333000 R15: ffff8aa9e1c2d600
> May 28 19:49:27 cassiopeiae kernel: FS: 00007fb0623dc1c0(0000)
> GS:ffff8ab15f8b9000(0000) knlGS:0000000000000000
> May 28 19:49:27 cassiopeiae kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033
> May 28 19:49:27 cassiopeiae kernel: CR2: 000000000000002c CR3:
> 000000011efcc000 CR4: 0000000000f50ef0
> May 28 19:49:27 cassiopeiae kernel: PKRU: 55555554
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
@ 2026-05-28 18:21 ` lyude
0 siblings, 0 replies; 21+ messages in thread
From: lyude @ 2026-05-28 18:21 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Hongling Zeng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, airlied, ttabi, bskeggs, dri-devel, nouveau, linux-kernel,
zhongling0719
Oh dear, thank you for catching this.
Would you mind sending a revert and I can give an R-B and push it?
On Thu, 2026-05-28 at 19:56 +0200, Danilo Krummrich wrote:
> On Thu May 28, 2026 at 6:41 PM CEST, lyude wrote:
> > Will push them to drm-misc in just a moment
>
> [...]
>
> > > nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage
>
> I think at least this patch has to be reverted, it causes the
> following oops
> probing nouveau on my machine.
>
> I can't currently look into this, but I think Sashiko [1] has a valid
> point on
> this one.
>
> [1]
> https://sashiko.dev/#/patchset/20260528062451.54107-1-zenghongling%40kylinos.cn
>
> May 28 19:49:27 cassiopeiae kernel: BUG: kernel NULL pointer
> dereference, address: 000000000000002c
> May 28 19:49:27 cassiopeiae kernel: #PF: supervisor read access in
> kernel mode
> May 28 19:49:27 cassiopeiae kernel: #PF: error_code(0x0000) - not-
> present page
> May 28 19:49:27 cassiopeiae kernel: PGD 0 P4D 0
> May 28 19:49:27 cassiopeiae kernel: Oops: Oops: 0000 [#1] SMP NOPTI
> May 28 19:49:27 cassiopeiae kernel: CPU: 12 UID: 0 PID: 475 Comm:
> (udev-worker) Not tainted 7.1.0-rc5+ #14 PREEMPT(lazy)
> May 28 19:49:27 cassiopeiae kernel: Hardware name: ASUS System
> Product Name/TUF GAMING B850-E WIFI, BIOS 1627 02/05/2026
> May 28 19:49:27 cassiopeiae kernel: RIP:
> 0010:r535_gsp_rpc_rm_ctrl_push+0x60/0x110 [nouveau]
> May 28 19:49:27 cassiopeiae kernel: Code: 4c 8b 58 08 4c 89 f7 ba 02
> 00 00 00 89 e9 2e 2e 2e 41 ff d3 48 89 c6 48 3d 01 f0 ff ff 72 0b 48
> c7 03 00 00 00 00 89>
> May 28 19:49:27 cassiopeiae kernel: RSP: 0018:ffffd3b38178f250
> EFLAGS: 00010213
> May 28 19:49:27 cassiopeiae kernel: RAX: 0000000000000020 RBX:
> ffffd3b38178f2a0 RCX: 0000000000000000
> May 28 19:49:27 cassiopeiae kernel: RDX: 0000000000000038 RSI:
> 0000000000000020 RDI: ffff8aa9db3339d8
> May 28 19:49:27 cassiopeiae kernel: RBP: 0000000000000000 R08:
> ffffffffbe380560 R09: ffffffffc04c9300
> May 28 19:49:27 cassiopeiae kernel: R10: 0000000000000100 R11:
> ffffffffbd66c070 R12: 0000000090f10000
> May 28 19:49:27 cassiopeiae kernel: R13: 0000000000000000 R14:
> ffff8aa9db333000 R15: ffff8aa9e1c2d600
> May 28 19:49:27 cassiopeiae kernel: FS: 00007fb0623dc1c0(0000)
> GS:ffff8ab15f8b9000(0000) knlGS:0000000000000000
> May 28 19:49:27 cassiopeiae kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033
> May 28 19:49:27 cassiopeiae kernel: CR2: 000000000000002c CR3:
> 000000011efcc000 CR4: 0000000000f50ef0
> May 28 19:49:27 cassiopeiae kernel: PKRU: 55555554
> May 28 19:49:27 cassiopeiae kernel: Call Trace:
> May 28 19:49:27 cassiopeiae kernel: <TASK>
> May 28 19:49:27 cassiopeiae kernel: r535_mmu_vaspace_new+0x1f8/0x520
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nvkm_uvmm_new+0x1b7/0x210
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nvkm_ioctl_new+0x22d/0x340
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: ? nvkm_uvmm_search+0x30/0x30
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nvkm_ioctl+0xf7/0x1f0 [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nvif_object_ctor+0x134/0x2b0
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: ? nvkm_uvmm_search+0x30/0x30
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: ? __kmalloc_noprof+0x205/0x550
> May 28 19:49:27 cassiopeiae kernel: ? nvif_vmm_ctor+0x65/0x280
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nvif_vmm_ctor+0xe5/0x280
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nouveau_vmm_init+0x3b/0x50
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: nouveau_cli_init+0x25f/0x450
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel:
> nouveau_drm_device_init+0x69/0x840 [nouveau]
> May 28 19:49:27 cassiopeiae kernel: ?
> pci_bus_read_config_word+0x4b/0x80
> May 28 19:49:27 cassiopeiae kernel: nouveau_drm_probe+0xc7/0x190
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: pci_device_probe+0x1f9/0x300
> May 28 19:49:27 cassiopeiae kernel: really_probe+0x1b8/0x480
> May 28 19:49:27 cassiopeiae kernel: __driver_probe_device+0x9d/0x130
> May 28 19:49:27 cassiopeiae kernel: driver_probe_device+0x1e/0x100
> May 28 19:49:27 cassiopeiae kernel: __driver_attach+0xab/0x210
> May 28 19:49:27 cassiopeiae kernel: ? driver_attach+0x20/0x20
> May 28 19:49:27 cassiopeiae kernel: bus_for_each_dev+0x10b/0x150
> May 28 19:49:27 cassiopeiae kernel: bus_add_driver+0x184/0x2d0
> May 28 19:49:27 cassiopeiae kernel: driver_register+0x61/0xf0
> May 28 19:49:27 cassiopeiae kernel: init_module+0x1bd/0x1000
> [nouveau]
> May 28 19:49:27 cassiopeiae kernel: ? cleanup_module+0x2e0/0x2e0
> [video]
> May 28 19:49:27 cassiopeiae kernel: do_one_initcall+0x12e/0x350
> May 28 19:49:27 cassiopeiae kernel: ?
> security_kernfs_init_security+0x58/0x130
> May 28 19:49:27 cassiopeiae kernel: ? __kernfs_new_node+0x1be/0x270
> May 28 19:49:27 cassiopeiae kernel: ?
> security_kernfs_init_security+0x58/0x130
> May 28 19:49:27 cassiopeiae kernel: ? __add_to_free_list+0x98/0x170
> May 28 19:49:27 cassiopeiae kernel: ? __free_one_page+0x34c/0x450
> May 28 19:49:27 cassiopeiae kernel: ? free_pcppages_bulk+0x19d/0x270
> May 28 19:49:27 cassiopeiae kernel: ?
> free_frozen_page_commit+0xaa/0x4b0
> May 28 19:49:27 cassiopeiae kernel: ?
> __free_frozen_pages+0x29e/0x670
> May 28 19:49:27 cassiopeiae kernel: ? load_module+0x1354/0x14e0
> May 28 19:49:27 cassiopeiae kernel: ?
> __kmalloc_cache_noprof+0x189/0x420
> May 28 19:49:27 cassiopeiae kernel: do_init_module+0x82/0x270
> May 28 19:49:27 cassiopeiae kernel:
> __se_sys_finit_module+0x26a/0x3d0
> May 28 19:49:27 cassiopeiae kernel: do_syscall_64+0x12a/0x3b0
> May 28 19:49:27 cassiopeiae kernel: ? vfs_read+0x14d/0x300
> May 28 19:49:27 cassiopeiae kernel: ? __x64_sys_pread64+0x70/0xc0
> May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0x165/0x3b0
> May 28 19:49:27 cassiopeiae kernel: ? do_sys_openat2+0x93/0xd0
> May 28 19:49:27 cassiopeiae kernel: ? __x64_sys_openat+0x80/0xa0
> May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0x165/0x3b0
> May 28 19:49:27 cassiopeiae kernel: ? __x64_sys_pread64+0x70/0xc0
> May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0x165/0x3b0
> May 28 19:49:27 cassiopeiae kernel: ? do_user_addr_fault+0x273/0x6a0
> May 28 19:49:27 cassiopeiae kernel: ? irqentry_exit+0x3f/0x630
> May 28 19:49:27 cassiopeiae kernel: ? do_syscall_64+0xe9/0x3b0
> May 28 19:49:27 cassiopeiae kernel:
> entry_SYSCALL_64_after_hwframe+0x67/0x6f
> May 28 19:49:27 cassiopeiae kernel: RIP: 0033:0x7fb062bb26bd
> May 28 19:49:27 cassiopeiae kernel: Code: ff c3 66 2e 0f 1f 84 00 00
> 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2
> 4d 89 c8 4c 8b 4c 24>
> May 28 19:49:27 cassiopeiae kernel: RSP: 002b:00007ffe2bae4d58
> EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> May 28 19:49:27 cassiopeiae kernel: RAX: ffffffffffffffda RBX:
> 000055b4032b23e0 RCX: 00007fb062bb26bd
> May 28 19:49:27 cassiopeiae kernel: RDX: 0000000000000000 RSI:
> 000055b403434900 RDI: 0000000000000043
> May 28 19:49:27 cassiopeiae kernel: RBP: 00007ffe2bae4df0 R08:
> 0000000000000000 R09: 0000000000000000
> May 28 19:49:27 cassiopeiae kernel: R10: 0000000000000000 R11:
> 0000000000000246 R12: 000055b403434900
> May 28 19:49:27 cassiopeiae kernel: R13: 000055b40340c570 R14:
> 0000000000020000 R15: 000055b403437260
> May 28 19:49:27 cassiopeiae kernel: </TASK>
> May 28 19:49:27 cassiopeiae kernel: Modules linked in: nouveau(+)
> drm_display_helper cec gpu_sched drm_gpuvm drm_exec drm_ttm_helper
> ttm nvme nvme_core nvme_k>
> May 28 19:49:27 cassiopeiae kernel: CR2: 000000000000002c
> May 28 19:49:27 cassiopeiae kernel: ---[ end trace 0000000000000000
> ]---
> May 28 19:49:27 cassiopeiae kernel: RIP:
> 0010:r535_gsp_rpc_rm_ctrl_push+0x60/0x110 [nouveau]
> May 28 19:49:27 cassiopeiae kernel: Code: 4c 8b 58 08 4c 89 f7 ba 02
> 00 00 00 89 e9 2e 2e 2e 41 ff d3 48 89 c6 48 3d 01 f0 ff ff 72 0b 48
> c7 03 00 00 00 00 89>
> May 28 19:49:27 cassiopeiae kernel: RSP: 0018:ffffd3b38178f250
> EFLAGS: 00010213
> May 28 19:49:27 cassiopeiae kernel: RAX: 0000000000000020 RBX:
> ffffd3b38178f2a0 RCX: 0000000000000000
> May 28 19:49:27 cassiopeiae kernel: RDX: 0000000000000038 RSI:
> 0000000000000020 RDI: ffff8aa9db3339d8
> May 28 19:49:27 cassiopeiae kernel: RBP: 0000000000000000 R08:
> ffffffffbe380560 R09: ffffffffc04c9300
> May 28 19:49:27 cassiopeiae kernel: R10: 0000000000000100 R11:
> ffffffffbd66c070 R12: 0000000090f10000
> May 28 19:49:27 cassiopeiae kernel: R13: 0000000000000000 R14:
> ffff8aa9db333000 R15: ffff8aa9e1c2d600
> May 28 19:49:27 cassiopeiae kernel: FS: 00007fb0623dc1c0(0000)
> GS:ffff8ab15f8b9000(0000) knlGS:0000000000000000
> May 28 19:49:27 cassiopeiae kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033
> May 28 19:49:27 cassiopeiae kernel: CR2: 000000000000002c CR3:
> 000000011efcc000 CR4: 0000000000f50ef0
> May 28 19:49:27 cassiopeiae kernel: PKRU: 55555554
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
2026-05-28 17:56 ` Danilo Krummrich
@ 2026-05-28 19:06 ` Timur Tabi
-1 siblings, 0 replies; 21+ messages in thread
From: Timur Tabi @ 2026-05-28 19:06 UTC (permalink / raw)
To: dakr@kernel.org, lyude@redhat.com
Cc: linux-kernel@vger.kernel.org, airlied@redhat.com, simona@ffwll.ch,
tzimmermann@suse.de, dri-devel@lists.freedesktop.org,
airlied@gmail.com, nouveau@lists.freedesktop.org,
maarten.lankhorst@linux.intel.com, zenghongling@kylinos.cn,
bskeggs@nvidia.com, mripard@kernel.org, zhongling0719@126.com
On Thu, 2026-05-28 at 19:56 +0200, Danilo Krummrich wrote:
> I think at least this patch has to be reverted, it causes the following oops
> probing nouveau on my machine.
>
> I can't currently look into this, but I think Sashiko [1] has a valid point on
> this one.
I'm not a fan of this series. When I saw the number of patches, I was suspicious, because I have a
hard time believing that there were so many functions that never returned NULL. The call tree of a
lot of Nouveau code is pretty deep, and it takes quite a lot of work to ensure that there is no
"return NULL" in any code path.
Nouveau is kinda sloppy in this regard, which is why IS_ERR_OR_NULL is used so much. It's a safety
measure.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
@ 2026-05-28 19:06 ` Timur Tabi
0 siblings, 0 replies; 21+ messages in thread
From: Timur Tabi @ 2026-05-28 19:06 UTC (permalink / raw)
To: dakr@kernel.org, lyude@redhat.com
Cc: linux-kernel@vger.kernel.org, airlied@redhat.com, simona@ffwll.ch,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
maarten.lankhorst@linux.intel.com, zenghongling@kylinos.cn,
bskeggs@nvidia.com, mripard@kernel.org, zhongling0719@126.com
On Thu, 2026-05-28 at 19:56 +0200, Danilo Krummrich wrote:
> I think at least this patch has to be reverted, it causes the following oops
> probing nouveau on my machine.
>
> I can't currently look into this, but I think Sashiko [1] has a valid point on
> this one.
I'm not a fan of this series. When I saw the number of patches, I was suspicious, because I have a
hard time believing that there were so many functions that never returned NULL. The call tree of a
lot of Nouveau code is pretty deep, and it takes quite a lot of work to ensure that there is no
"return NULL" in any code path.
Nouveau is kinda sloppy in this regard, which is why IS_ERR_OR_NULL is used so much. It's a safety
measure.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
2026-05-28 19:06 ` Timur Tabi
@ 2026-05-28 19:09 ` lyude
-1 siblings, 0 replies; 21+ messages in thread
From: lyude @ 2026-05-28 19:09 UTC (permalink / raw)
To: Timur Tabi, dakr@kernel.org
Cc: linux-kernel@vger.kernel.org, airlied@redhat.com, simona@ffwll.ch,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
maarten.lankhorst@linux.intel.com, zenghongling@kylinos.cn,
bskeggs@nvidia.com, mripard@kernel.org, zhongling0719@126.com
On Thu, 2026-05-28 at 19:06 +0000, Timur Tabi wrote:
> On Thu, 2026-05-28 at 19:56 +0200, Danilo Krummrich wrote:
> > I think at least this patch has to be reverted, it causes the
> > following oops
> > probing nouveau on my machine.
> >
> > I can't currently look into this, but I think Sashiko [1] has a
> > valid point on
> > this one.
>
> I'm not a fan of this series. When I saw the number of patches, I
> was suspicious, because I have a
> hard time believing that there were so many functions that never
> returned NULL. The call tree of a
> lot of Nouveau code is pretty deep, and it takes quite a lot of work
> to ensure that there is no
> "return NULL" in any code path.
>
> Nouveau is kinda sloppy in this regard, which is why IS_ERR_OR_NULL
> is used so much. It's a safety
> measure.
FWIW: I already sent a revert for the last patch in the series which
needs a review, but I'm happy to send out a revert for the whole thing
if we want.
You are right - I did actually sit down and try to run through all of
the codepaths for all these functions, but there's clearly a number
that I missed and should have checked sashiko for.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
@ 2026-05-28 19:09 ` lyude
0 siblings, 0 replies; 21+ messages in thread
From: lyude @ 2026-05-28 19:09 UTC (permalink / raw)
To: Timur Tabi, dakr@kernel.org
Cc: linux-kernel@vger.kernel.org, airlied@redhat.com, simona@ffwll.ch,
tzimmermann@suse.de, dri-devel@lists.freedesktop.org,
airlied@gmail.com, nouveau@lists.freedesktop.org,
maarten.lankhorst@linux.intel.com, zenghongling@kylinos.cn,
bskeggs@nvidia.com, mripard@kernel.org, zhongling0719@126.com
On Thu, 2026-05-28 at 19:06 +0000, Timur Tabi wrote:
> On Thu, 2026-05-28 at 19:56 +0200, Danilo Krummrich wrote:
> > I think at least this patch has to be reverted, it causes the
> > following oops
> > probing nouveau on my machine.
> >
> > I can't currently look into this, but I think Sashiko [1] has a
> > valid point on
> > this one.
>
> I'm not a fan of this series. When I saw the number of patches, I
> was suspicious, because I have a
> hard time believing that there were so many functions that never
> returned NULL. The call tree of a
> lot of Nouveau code is pretty deep, and it takes quite a lot of work
> to ensure that there is no
> "return NULL" in any code path.
>
> Nouveau is kinda sloppy in this regard, which is why IS_ERR_OR_NULL
> is used so much. It's a safety
> measure.
FWIW: I already sent a revert for the last patch in the series which
needs a review, but I'm happy to send out a revert for the whole thing
if we want.
You are right - I did actually sit down and try to run through all of
the codepaths for all these functions, but there's clearly a number
that I missed and should have checked sashiko for.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
2026-05-28 19:09 ` lyude
@ 2026-05-28 19:19 ` Timur Tabi
-1 siblings, 0 replies; 21+ messages in thread
From: Timur Tabi @ 2026-05-28 19:19 UTC (permalink / raw)
To: lyude@redhat.com, dakr@kernel.org
Cc: airlied@redhat.com, tzimmermann@suse.de, simona@ffwll.ch,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
airlied@gmail.com, maarten.lankhorst@linux.intel.com,
zenghongling@kylinos.cn, bskeggs@nvidia.com,
linux-kernel@vger.kernel.org, zhongling0719@126.com,
mripard@kernel.org
On Thu, 2026-05-28 at 15:09 -0400, lyude@redhat.com wrote:
> You are right - I did actually sit down and try to run through all of
> the codepaths for all these functions, but there's clearly a number
> that I missed and should have checked sashiko for.
Even if you could narrow down the list to those functions that are 100% okay with IS_ERR, that's not
future proof. I wouldn't be surprised if there are some code paths where IS_ERR_OR_NULL is
required, but then the NULL is converted to an ERR, and so the top-level caller will see only ERR.
But what happens if there's a refactor or some other major code change?
Like I implied earlier, the real problem is that Nouveau is inconsistent in how it returns failure.
Sometimes it returns NULL, sometimes it returns ERR, sometimes it could be either. So a proper fix
is not replacing IS_ERR_OR_NULL with IS_ERR wherever we can get away with it today. The proper fix
is to revamp the entire code base to be consistent, and no one wants to do that work.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
@ 2026-05-28 19:19 ` Timur Tabi
0 siblings, 0 replies; 21+ messages in thread
From: Timur Tabi @ 2026-05-28 19:19 UTC (permalink / raw)
To: lyude@redhat.com, dakr@kernel.org
Cc: airlied@redhat.com, simona@ffwll.ch,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
maarten.lankhorst@linux.intel.com, zenghongling@kylinos.cn,
bskeggs@nvidia.com, linux-kernel@vger.kernel.org,
zhongling0719@126.com, mripard@kernel.org
On Thu, 2026-05-28 at 15:09 -0400, lyude@redhat.com wrote:
> You are right - I did actually sit down and try to run through all of
> the codepaths for all these functions, but there's clearly a number
> that I missed and should have checked sashiko for.
Even if you could narrow down the list to those functions that are 100% okay with IS_ERR, that's not
future proof. I wouldn't be surprised if there are some code paths where IS_ERR_OR_NULL is
required, but then the NULL is converted to an ERR, and so the top-level caller will see only ERR.
But what happens if there's a refactor or some other major code change?
Like I implied earlier, the real problem is that Nouveau is inconsistent in how it returns failure.
Sometimes it returns NULL, sometimes it returns ERR, sometimes it could be either. So a proper fix
is not replacing IS_ERR_OR_NULL with IS_ERR wherever we can get away with it today. The proper fix
is to revamp the entire code base to be consistent, and no one wants to do that work.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
2026-05-28 19:19 ` Timur Tabi
@ 2026-05-28 19:21 ` lyude
-1 siblings, 0 replies; 21+ messages in thread
From: lyude @ 2026-05-28 19:21 UTC (permalink / raw)
To: Timur Tabi, dakr@kernel.org
Cc: airlied@redhat.com, tzimmermann@suse.de, simona@ffwll.ch,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
airlied@gmail.com, maarten.lankhorst@linux.intel.com,
zenghongling@kylinos.cn, bskeggs@nvidia.com,
linux-kernel@vger.kernel.org, zhongling0719@126.com,
mripard@kernel.org
On Thu, 2026-05-28 at 19:19 +0000, Timur Tabi wrote:
> On Thu, 2026-05-28 at 15:09 -0400, lyude@redhat.com wrote:
> > You are right - I did actually sit down and try to run through all
> > of
> > the codepaths for all these functions, but there's clearly a number
> > that I missed and should have checked sashiko for.
>
> Even if you could narrow down the list to those functions that are
> 100% okay with IS_ERR, that's not
> future proof. I wouldn't be surprised if there are some code paths
> where IS_ERR_OR_NULL is
> required, but then the NULL is converted to an ERR, and so the top-
> level caller will see only ERR.
> But what happens if there's a refactor or some other major code
> change?
>
> Like I implied earlier, the real problem is that Nouveau is
> inconsistent in how it returns failure.
> Sometimes it returns NULL, sometimes it returns ERR, sometimes it
> could be either. So a proper fix
> is not replacing IS_ERR_OR_NULL with IS_ERR wherever we can get away
> with it today. The proper fix
> is to revamp the entire code base to be consistent, and no one wants
> to do that work.
Yeah - that's a good point. I will go ahead and send the revert for the
whole series then, would you mind helping to review it?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
@ 2026-05-28 19:21 ` lyude
0 siblings, 0 replies; 21+ messages in thread
From: lyude @ 2026-05-28 19:21 UTC (permalink / raw)
To: Timur Tabi, dakr@kernel.org
Cc: airlied@redhat.com, simona@ffwll.ch,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
maarten.lankhorst@linux.intel.com, zenghongling@kylinos.cn,
bskeggs@nvidia.com, linux-kernel@vger.kernel.org,
zhongling0719@126.com, mripard@kernel.org
On Thu, 2026-05-28 at 19:19 +0000, Timur Tabi wrote:
> On Thu, 2026-05-28 at 15:09 -0400, lyude@redhat.com wrote:
> > You are right - I did actually sit down and try to run through all
> > of
> > the codepaths for all these functions, but there's clearly a number
> > that I missed and should have checked sashiko for.
>
> Even if you could narrow down the list to those functions that are
> 100% okay with IS_ERR, that's not
> future proof. I wouldn't be surprised if there are some code paths
> where IS_ERR_OR_NULL is
> required, but then the NULL is converted to an ERR, and so the top-
> level caller will see only ERR.
> But what happens if there's a refactor or some other major code
> change?
>
> Like I implied earlier, the real problem is that Nouveau is
> inconsistent in how it returns failure.
> Sometimes it returns NULL, sometimes it returns ERR, sometimes it
> could be either. So a proper fix
> is not replacing IS_ERR_OR_NULL with IS_ERR wherever we can get away
> with it today. The proper fix
> is to revamp the entire code base to be consistent, and no one wants
> to do that work.
Yeah - that's a good point. I will go ahead and send the revert for the
whole series then, would you mind helping to review it?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
2026-05-28 19:21 ` lyude
@ 2026-05-28 19:22 ` Timur Tabi
-1 siblings, 0 replies; 21+ messages in thread
From: Timur Tabi @ 2026-05-28 19:22 UTC (permalink / raw)
To: lyude@redhat.com, dakr@kernel.org
Cc: linux-kernel@vger.kernel.org, airlied@redhat.com, simona@ffwll.ch,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
airlied@gmail.com, maarten.lankhorst@linux.intel.com,
zenghongling@kylinos.cn, tzimmermann@suse.de, bskeggs@nvidia.com,
zhongling0719@126.com, mripard@kernel.org
On Thu, 2026-05-28 at 15:21 -0400, lyude@redhat.com wrote:
> Yeah - that's a good point. I will go ahead and send the revert for the
> whole series then, would you mind helping to review it?
Sure.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
@ 2026-05-28 19:22 ` Timur Tabi
0 siblings, 0 replies; 21+ messages in thread
From: Timur Tabi @ 2026-05-28 19:22 UTC (permalink / raw)
To: lyude@redhat.com, dakr@kernel.org
Cc: linux-kernel@vger.kernel.org, airlied@redhat.com, simona@ffwll.ch,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
maarten.lankhorst@linux.intel.com, zenghongling@kylinos.cn,
bskeggs@nvidia.com, zhongling0719@126.com, mripard@kernel.org
On Thu, 2026-05-28 at 15:21 -0400, lyude@redhat.com wrote:
> Yeah - that's a good point. I will go ahead and send the revert for the
> whole series then, would you mind helping to review it?
Sure.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2026-05-28 19:22 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-28 6:24 [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage Hongling Zeng
2026-05-28 6:24 ` [PATCH 1/5] nouveau/gsp: cleanup IS_ERR_OR_NULL in rm_alloc functions Hongling Zeng
2026-05-28 6:24 ` [PATCH 2/5] nouveau/gsp: cleanup IS_ERR_OR_NULL in rpc_rd Hongling Zeng
2026-05-28 6:24 ` [PATCH 3/5] nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation Hongling Zeng
2026-05-28 6:24 ` [PATCH 4/5] nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL) Hongling Zeng
2026-05-28 6:24 ` [PATCH 5/5] nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage Hongling Zeng
2026-05-28 16:41 ` [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage lyude
2026-05-28 17:56 ` Danilo Krummrich
2026-05-28 17:56 ` Danilo Krummrich
2026-05-28 18:21 ` lyude
2026-05-28 18:21 ` lyude
2026-05-28 19:06 ` Timur Tabi
2026-05-28 19:06 ` Timur Tabi
2026-05-28 19:09 ` lyude
2026-05-28 19:09 ` lyude
2026-05-28 19:19 ` Timur Tabi
2026-05-28 19:19 ` Timur Tabi
2026-05-28 19:21 ` lyude
2026-05-28 19:21 ` lyude
2026-05-28 19:22 ` Timur Tabi
2026-05-28 19:22 ` Timur Tabi
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.