From: sashiko-bot@kernel.org
To: "Haotian Zhang" <vulab@iscas.ac.cn>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: fix NULL RAS context dereference in UMC page retirement
Date: Thu, 08 Oct 2026 16:23:00 +0000 [thread overview]
Message-ID: <sashiko-outbox-164377@kernel.org> (raw)
In-Reply-To: <20261008161144.2671028-1-vulab@iscas.ac.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] amdgpu: KFD queue permanently hung when RAS is disabled due to bypassed GPU reset
--
commit 8cb95b8549bf147ff94f08bcdd4e5a3aaa6812ae
Author: Haotian Zhang <vulab@iscas.ac.cn>
drm/amdgpu: fix NULL RAS context dereference in UMC page retirement
amdgpu_umc_handle_bad_pages() and amdgpu_umc_do_page_retirement() take the
RAS context from amdgpu_ras_get_context() and dereference it without
checking for NULL. That context is NULL whenever RAS is disabled.
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c
> index 34702e5cb1b6c..283180e3f2db2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c
[ ... ]
> @@ -217,6 +221,9 @@ static int amdgpu_umc_do_page_retirement(struct amdgpu_device *adev,
> kgd2kfd_set_sram_ecc_flag(adev->kfd.dev);
> amdgpu_umc_handle_bad_pages(adev, ras_error_status);
>
> + if (!con)
> + return AMDGPU_RAS_SUCCESS;
> +
[Severity: High]
Does this early return ignore the reset parameter requested by the caller?
When KFD encounters a poison consumption error and requests a fallback GPU
reset by passing a non-zero reset flag, returning AMDGPU_RAS_SUCCESS here
without handling the reset leaves the KFD queue permanently hung.
This leaves the hardware in an unrecoverable state until the next system
reboot.
Should this trigger a generic GPU reset via amdgpu_device_gpu_recover()
when the context is NULL?
Also, is there a similar regression in amdgpu_umc_pasid_poison_handler()?
if (adev->gmc.xgmi.connected_to_cpu ||
adev->gmc.is_app_apu) {
if (reset) {
/* MCA poison handler is only responsible for GPU reset,
* let MCA notifier do page retirement.
*/
kgd2kfd_set_sram_ecc_flag(adev->kfd.dev);
amdgpu_ras_reset_gpu(adev);
}
return ret;
}
If reset is requested and xgmi.connected_to_cpu is true, this unconditionally
calls amdgpu_ras_reset_gpu().
Can this still trigger a NULL pointer dereference inside amdgpu_ras_reset_gpu()
when RAS is disabled?
> if ((err_data->ue_count || err_data->de_count) &&
> (reset || amdgpu_ras_is_rma(adev))) {
> con->gpu_reset_flags |= reset;
> amdgpu_ras_reset_gpu(adev);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261008161144.2671028-1-vulab@iscas.ac.cn?part=1
prev parent reply other threads:[~2026-10-08 16:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 16:11 [PATCH] drm/amdgpu: fix NULL RAS context dereference in UMC page retirement Haotian Zhang
2026-10-08 16:23 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-164377@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vulab@iscas.ac.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.