Re: [PATCH V20 12/15] drm/xe/vram: Check disable_vram_page_offline policy in fault handler

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unratelimited error logging in the VRAM address fault handler can cause dmesg flooding and DoS.
--

commit 5bfee849427fab2b54c95eec2934afe083fd4e87
Author: Tejas Upadhyay <tejas.upadhyay@intel.com>

drm/xe/vram: Check disable_vram_page_offline policy in fault handler

This commit introduces a check in the VRAM address fault handler to verify the
disable_vram_page_offline policy. If enabled, it logs the corrupted address
and returns -EOPNOTSUPP so that RAS can report it without attempting to offline
the page.

> diff --git a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> index 0ab92bc3c6998..00569c5279a83 100644
> --- a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> +++ b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
[ ... ]
> @@ -906,6 +907,12 @@ int xe_ttm_vram_handle_addr_fault(struct xe_device *xe, u64 addr)
>  	vram_mgr = &vr->ttm;
>  	mm = &vram_mgr->mm;
>  
> +	if (xe->ras.disable_vram_page_offline) {
> +		xe_err(xe, "0x%llx is reported as corrupted address by HW\n",
> +		       addr);

[Severity: Medium]
Since this page is intentionally kept online and not offlined, can a corrupted
VRAM page accessed in a tight loop by a userspace application, or polled
continuously by the hardware, cause a log flood here?

Could this use a rate-limited logging function to prevent a potential local
Denial of Service (DoS) from continuous dmesg writes, especially on systems
with serial consoles?

> +		return -EOPNOTSUPP;
> +	}
> +
>  	/* Reserve page at address */
>  	return xe_ttm_vram_reserve_page_at_addr(xe, addr - vr->dpa_base, vram_mgr, mm);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902145343.465686-17-tejas.upadhyay@intel.com?part=12