[PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage

Hongling Zeng posted 5 patches 1 week, 4 days ago
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(-)
[PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
Posted by Hongling Zeng 1 week, 4 days ago
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
Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
Posted by lyude@redhat.com 1 week, 3 days ago
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
Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
Posted by Danilo Krummrich 1 week, 3 days ago
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
Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
Posted by Timur Tabi 1 week, 3 days ago
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.

Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
Posted by lyude@redhat.com 1 week, 3 days ago
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. 
Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
Posted by Timur Tabi 1 week, 3 days ago
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.
Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
Posted by lyude@redhat.com 1 week, 3 days ago
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?
Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
Posted by Timur Tabi 1 week, 3 days ago
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.
Re: [PATCH 0/5] nouveau/gsp: Cleanup IS_ERR_OR_NULL() usage
Posted by lyude@redhat.com 1 week, 3 days ago
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