Re: [PATCH v6 0/3] Fix kernel crash during driver teardown

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Mon, Oct 12, 2026 at 09:30:54AM +0000, Satyanarayana K V P wrote:
> During driver release, the hardware engine is only partially invalidated
> during teardown. Its name remains set, so the memory IRQ handler can still
> identify the engine and access its state after teardown. This can result
> in a NULL pointer dereference.
> 
> Invalidate the hardware engine name during teardown so the IRQ handler no
> longer treats the engine as available.
> 
> The crash log below shows an example of the failure.
> 
> BUG: kernel NULL pointer dereference, address: 0000000000000000
> PF: supervisor read access in kernel mode
> PF: error_code(0x0000) - not-present page
> PGD 0 P4D 0
> Oops: Oops: 0000 [#1] SMP NOPTI
> Tainted: [U]=USER
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> 2025.11-3ubuntu7 03/31/2026
> RIP: 0010:xe_hw_engine_handle_irq+0x18/0x70 [xe]
> Code: 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f
> 44 00 00 55 48 89 e5 41 54 41 89 f4 48 89 d6 53 48 8b 07 48 89 fb <48> 8b 00 48
> 8b 38 e8 5d 84 08 00 48 8b 83 b8 00 00 00 48 85 c0 74
> RSP: 0018:ffffd07840003e80 EFLAGS: 00010046
> RAX: 0000000000000000 RBX: ffff8904657fa740 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8904657fa740
> RBP: ffffd07840003e90 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
> R13: ffff89046a490000 R14: ffff89046a491af8 R15: ffff8904657faf20
> FS:  0000000000000000(0000) GS:ffff8905fd219000(0000)
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 0000000103705005 CR4: 0000000000772ef0
> PKRU: 55555554
> Call Trace:
>  <IRQ>
>  xe_memirq_handler+0xc3/0x200 [xe]
>  vf_mem_irq_handler+0x46/0x90 [xe]
>  __handle_irq_event_percpu+0x59/0x200
>  handle_irq_event+0x36/0x90
>  handle_edge_irq+0xc5/0x190
>  __common_interrupt+0x50/0x160
>  ? irq_enter_rcu+0x84/0xb0
>  common_interrupt+0xb0/0xe0
>  </IRQ>


I believe issues like this prove's Danilo's point on his LPC
presentation [1] right?!

[1] https://www.youtube.com/live/QkKqzX2Vv4c?si=FUEfOoBA5q_ZkoXL&t=19761

And sashiko shows that it might be harder... I wonder if there are some
layering split we could do here to proper handle this lifetime and
ownership clear without a major refactoring :/

> 
> ---
> V5 -> V6:
> - Return DRM_GPU_SCHED_STAT_NO_HANG instead of DRM_GPU_SCHED_STAT_ENODEV
>  (Piotr)
> 
> V4 -> V5: 
> - Return DRM_GPU_SCHED_STAT_ENODEV instead of DRM_GPU_SCHED_STAT_NO_HANG
> (Sashiko).
> V3 -> V4:
> - Fix race condition reported by LLM (Sashiko).
> 
> V2 -> V3:
> - Fixed race condition with guc_exec_queue_timedout_job(). (Sashiko).
> - Disable GT reset worker before engine teardown (LLM).
> 
> V1 -> V2:
> - Fix race with xe_memirq_handler() and hw_engine_fini() (Sashiko & Piotr).
> 
> Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
> Assisted-by: LLM
> 
> Satyanarayana K V P (3):
>   drm/xe: Prevent VF memory IRQ from accessing a torn-down engine
>   drm/xe/guc: Protect timeout handling from device unplug
>   drm/xe/gt: Disable GT reset worker before engine teardown
> 
>  drivers/gpu/drm/xe/xe_gt.c         | 29 ++++++++++++++++++++++-------
>  drivers/gpu/drm/xe/xe_guc_submit.c | 12 +++++++++++-
>  drivers/gpu/drm/xe/xe_hw_engine.c  | 17 ++++++++++++++---
>  drivers/gpu/drm/xe/xe_irq.c        |  3 +++
>  drivers/gpu/drm/xe/xe_memirq.c     |  3 +++
>  5 files changed, 53 insertions(+), 11 deletions(-)
> 
> -- 
> 2.43.0
>