wireguard-linux/drivers/gpu/drm/xe/xe_devcoredump.c, branch jd/bump-compilers

drm/xe: Increase devcoredump timeout

2024-06-12T15:29:37Z

5 minutes is too short for a regular user to search and understand what he needs to do to report capture devcoredump and report a bug to us, so here increasing this timeout to 1 hour. Cc: Rodrigo Vivi Cc: Jonathan Cavitt Reviewed-by: Rodrigo Vivi Reviewed-by: Jonathan Cavitt Signed-off-by: José Roberto de Souza Link: https://patchwork.freedesktop.org/patch/msgid/20240611174716.72660-2-jose.souza@intel.com Signed-off-by: Rodrigo Vivi

drm/xe: Fix NULL ptr dereference in devcoredump

2024-05-31T17:31:09Z

Kernel VM do not have an Xe file. Include a check for Xe file in the VM before trying to get pid from VM's Xe file when taking a devcoredump. Fixes: b10d0c5e9df7 ("drm/xe: Add process name to devcoredump") Cc: Rodrigo Vivi Cc: José Roberto de Souza Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost Reviewed-by: José Roberto de Souza Link: https://patchwork.freedesktop.org/patch/msgid/20240530203341.1795181-1-matthew.brost@intel.com

drm/xe: replace format-less snprintf() with strscpy()

2024-05-30T16:57:26Z

Using snprintf() with a format string from task->comm is a bit dangerous since the string may be controlled by unprivileged userspace: drivers/gpu/drm/xe/xe_devcoredump.c: In function 'devcoredump_snapshot': drivers/gpu/drm/xe/xe_devcoredump.c:184:9: error: format not a string literal and no format arguments [-Werror=format-security] 184 | snprintf(ss->process_name, sizeof(ss->process_name), process_name); | ^~~~~~~~ In this case there is no reason for an snprintf(), so use a simpler string copy. Fixes: b10d0c5e9df7 ("drm/xe: Add process name to devcoredump") Signed-off-by: Arnd Bergmann Reviewed-by: Thomas Hellström Signed-off-by: Thomas Hellström Link: https://patchwork.freedesktop.org/patch/msgid/20240528133251.2310868-1-arnd@kernel.org

drm/xe: Add process name to devcoredump

2024-05-23T17:37:56Z

Process name help us track what application caused the gpug hang, this is crucial when running several applications at the same time. v2: - handle Xe KMD exec_queues without VM v3: - use get_pid_task() (suggested by Nirmoy) Cc: Rodrigo Vivi Cc: Nirmoy Das Signed-off-by: José Roberto de Souza Link: https://patchwork.freedesktop.org/patch/msgid/20240522201203.145403-1-jose.souza@intel.com Signed-off-by: Rodrigo Vivi

drm/xe/coredump: move over to devm

2024-05-22T12:22:39Z

Here we are using drmm to ensure we release the coredump when unloading the module, however the coredump is very much tied to the struct device underneath. We can see this when we hotunplug the device, for which we have already got a coredump attached. In such a case the coredump still remains and adding another is not possible. However we still register the release action via xe_driver_devcoredump_fini(), so in effect two or more releases for one dump. The other consideration is that the coredump state is embedded in the xe_driver instance, so technically once the drmm release action fires we might free the coredumpe state from a different driver instance, assuming we have two release actions and they can race. Rather use devm here to remove the coredump when the device is released. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1679 Signed-off-by: Matthew Auld Cc: Andrzej Hajda Cc: Rodrigo Vivi Reviewed-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20240522102143.128069-29-matthew.auld@intel.com

drm/xe: Remove devcoredump during driver release

2024-04-11T13:39:48Z

This will remove devcoredump from file system and free its resources during driver unload. This fix the driver unload after gpu hang happened, otherwise this it would report that Xe KMD is still in use and it would leave the kernel in a state that Xe KMD can't be unload without a reboot. Cc: Rodrigo Vivi Cc: Jonathan Cavitt Acked-by: Jonathan Cavitt Signed-off-by: José Roberto de Souza Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20240409200206.108452-2-jose.souza@intel.com Signed-off-by: Rodrigo Vivi

drm/xe: Always capture exec queues on snapshot

2024-04-08T21:47:37Z

Always capture exec queues on snapshot regardless if exec queue has pending jobs or not. Having jobs or not does indicate whether the exec queue capture is useful. Example bugs that would not be easily detected by skipping capture when pending job list is empty: - Jobs pending on exec queue have dependencies - Leaking exec queue refs - GuC protocol issues (i.e. losing G2H) In addition to above bugs, in general it just useful to see every exec queue registered with the GuC and its state. Cc: Rodrigo Vivi Signed-off-by: Matthew Brost Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20240405211632.223568-2-matthew.brost@intel.com

drm/xe/xe_devcoredump: Check NULL before assignments

2024-03-29T15:28:43Z

Assign 'xe_devcoredump_snapshot *' and 'xe_device *' only if 'coredump' is not NULL. v2 - Fix commit messages. v3 - Define variables before code.(Ashutosh/Jose) v4 - Drop return check for coredump_to_xe. (Jose/Rodrigo) v5 - Modify misleading commit message. (Matt) Cc: Matt Roper Cc: Ashutosh Dixit Cc: José Roberto de Souza Cc: Rodrigo Vivi Signed-off-by: Himal Prasad Ghimiray Reviewed-by: Rodrigo Vivi Reviewed-by: José Roberto de Souza Link: https://patchwork.freedesktop.org/patch/msgid/20240328123739.3633428-1-himal.prasad.ghimiray@intel.com Signed-off-by: Rodrigo Vivi

drm/xe/devcoredump: Print errno if VM snapshot was not captured

2024-03-22T15:08:47Z

My testing machine has only 8GB of RAM and while running piglit tests I can reach the OOM cache in xe_vm_snapshot_capture() snap allocaiton sometimes. So to differentiate the OOM from race between capture and UMDs unbinbind VMs here I'm adding a '[0].error: -12' to devcoredump. v2: - fix returned errno values Cc: Maarten Lankhorst Reviewed-by: Maarten Lankhorst Signed-off-by: José Roberto de Souza Link: https://patchwork.freedesktop.org/patch/msgid/20240307135229.41973-2-jose.souza@intel.com

drm/xe: Always check force_wake_get return code

2024-03-20T21:13:58Z

A force_wake_get failure means that the HW might not be awake for the access we're doing; this can lead to an immediate error or it can be a more subtle problem (e.g. a register read might return an incorrect value that is still valid, leading the driver to make a wrong choice instead of flagging an error). We avoid an error from the force_wake function because callers might handle or tolerate the error, but this only works if all callers are checking the error code. The majority already do, but a few are not. These are mainly falling into 3 categories, which are each handled differently: 1) error capture: in this case we want to continue the capture, but we log an info message in dmesg to notify the user that the capture might have incorrect data. 2) ioctl: in this case we return a -EIO error to userspace 3) unabortable actions: these are scenarios where we can't simply abort and retry and so it's better to just try it anyway because there is a chance the HW is awake even with the failure. In this case we throw a warning so we know there was a forcewake problem if something fails down the line. v2: use gt_WARN_ON where appropriate Signed-off-by: Daniele Ceraolo Spurio Cc: Tejas Upadhyay Reviewed-by: Matt Roper Reviewed-by: Tejas Upadhyay Link: https://patchwork.freedesktop.org/patch/msgid/20240318154924.3453513-1-daniele.ceraolospurio@intel.com