[GSD-12610] clEnqueueSVMMemcpy with invalid destination pointer and committed source buffer wedges process unkillably (i915 kernel regression)

[pvelesko]

Pre-submission Checklist

• I am using the latest GPU driver version (releases)
• I have searched for similar issues and found none

GPU Hardware

Tested on Intel Arc A380 (dGPU) and Intel UHD 730 (iGPU) — both hang.
Does NOT reproduce on Intel Arc A770 or UHD 770 (different kernel version — see below).

OS / Kernel

• Hangs: Ubuntu 24.04.3, kernel 6.17.0-20-generic
• Works: Ubuntu 24.04.2, kernel 6.17.0-14-generic

OpenCL Runtime Version

Driver Version: 26.09.37435.1
intel-opencl-icd 26.09.37435.1-0
intel-igc-core-2 2.30.1
intel-igc-opencl-2 2.30.1

Identical on both machines.

Summary

clEnqueueSVMMemcpy called with a destination pointer that is not a valid SVM/USM allocation should return CL_INVALID_VALUE or CL_OUT_OF_RESOURCES. On kernel 6.17.0-20 it instead enters a kernel-mode CPU loop in i915_gem_object_userptr_submit_init that makes the process unkillable — SIGKILL from root has no effect. Recovery requires rebooting the host.

On kernel 6.17.0-14 (same OpenCL driver, same hardware family), the call correctly returns -5 (CL_OUT_OF_RESOURCES) immediately.

Three conditions required to trigger

1. Invalid SVM destination pointer (e.g. 0xdeadbeef — not a valid clSVMAlloc or USM allocation)
2. Large transfer size (tested at 4 GB)
3. Source buffer must have committed physical pages (malloc + memset). Uncommitted pages (mmap MAP_NORESERVE) take a different code path that correctly returns -5.

Minimal reproducer

#define CL_TARGET_OPENCL_VERSION 300
#include <CL/cl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char** argv) {
    int plat_idx = (argc >= 2) ? atoi(argv[1]) : 0;
    size_t mb    = (argc >= 3) ? (size_t)atoll(argv[2]) : 4096;
    size_t bytes = mb * 1024ull * 1024ull;

    cl_int err;
    cl_uint nplats = 0;
    clGetPlatformIDs(0, NULL, &nplats);
    cl_platform_id plats[8];
    clGetPlatformIDs(nplats < 8 ? nplats : 8, plats, NULL);
    cl_device_id dev;
    clGetDeviceIDs(plats[plat_idx], CL_DEVICE_TYPE_GPU, 1, &dev, NULL);

    char dname[256] = {0};
    clGetDeviceInfo(dev, CL_DEVICE_NAME, sizeof dname, dname, NULL);
    fprintf(stderr, "Device: %s, size: %zu MB\n", dname, mb);

    cl_context ctx = clCreateContext(NULL, 1, &dev, NULL, NULL, &err);
    cl_command_queue q = clCreateCommandQueueWithProperties(ctx, dev, NULL, &err);

    /* Committed source buffer — must be malloc+memset, not mmap */
    char* h = (char*)malloc(bytes);
    if (!h) { fprintf(stderr, "malloc failed\n"); return 3; }
    memset(h, 0xab, bytes);

    void* d = (void*)0xdeadbeefULL;  /* NOT a valid SVM allocation */

    fprintf(stderr, "clEnqueueSVMMemcpy dst=%p size=%zu\n", d, bytes);
    err = clEnqueueSVMMemcpy(q, CL_FALSE, d, h, bytes, 0, NULL, NULL);
    fprintf(stderr, "enqueue returned %d\n", (int)err);

    /* Expected: err != 0 (rejected).
       Observed on 6.17.0-20: process is already wedged above,
       never reaches this line. */
    if (err == CL_SUCCESS) {
        fprintf(stderr, "clFinish...\n");
        err = clFinish(q);
        fprintf(stderr, "clFinish returned %d\n", (int)err);
    }

    free(h);
    return (err != CL_SUCCESS) ? 0 : 1;
}

Build and run:

gcc -O2 cl_badptr.c -lOpenCL -o cl_badptr
# WARNING: on affected kernels this will wedge one CPU core until reboot
timeout --kill-after=10s 30s ./cl_badptr 0 4096

Results

Machine	Kernel	GPU	Result
cupcake	6.17.0-14-generic	Arc A770	enqueue returned -5 — OK
cupcake	6.17.0-14-generic	UHD 770	enqueue returned -5 — OK
meatloaf	6.17.0-20-generic	Arc A380	HANG at clEnqueueSVMMemcpy (exit 137)
meatloaf	6.17.0-20-generic	UHD 730	HANG at clEnqueueSVMMemcpy (exit 137)

With mmap(MAP_NORESERVE) instead of malloc+memset for the source, all four combinations pass (return -5). The committed-pages requirement points to the i915 userptr/scatter-gather DMA setup path.

Kernel call trace (dmesg hung_task watchdog, from earlier investigation)

intel_iommu_map_pages+0xe7/0x140
iommu_map_nosync+0x133/0x2b0
iommu_map_sg+0xc8/0x1b0
iommu_dma_map_sg+0x59a/0x630
 ? i915_gem_shrink+0x6af/0x7a0 [i915]
__dma_map_sg_attrs+0x13b/0x1b0
dma_map_sg_attrs+0xe/0x30
i915_gem_gtt_prepare_pages+0x55/0x90 [i915]
i915_gem_userptr_get_pages+0xf3/0x200 [i915]
____i915_gem_object_get_pages+0x23/0x70 [i915]
i915_gem_object_userptr_submit_init+0x38c/0x420 [i915]
eb_lookup_vmas+0x141/0x290 [i915]

Process state while wedged

State:   R (running)
SigBlk:  0000000000000000
WCHAN:   -
%CPU:    99.9

On-CPU inside a kernel function, no pending signals checked.

Impact

• Wedged process does NOT poison the GPU for other workloads.
• Permanently consumes one CPU core and several GB of RSS.
• Only host reboot clears it.

Notes

• We discovered this via chipStar (a HIP-on-SPIR-V/OpenCL implementation). chipStar uses clEnqueueSVMMemcpy for hipMemcpy in its Intel USM allocation strategy. When a HIP application ignores a failed hipMalloc and proceeds to hipMemcpy with the invalid pointer, chipStar forwards it to clEnqueueSVMMemcpy, hitting this bug.
• The OpenCL runtime could also add defense-in-depth by validating SVM pointers before delegating to the kernel, but the root cause appears to be an i915 kernel regression between 6.17.0-14 and 6.17.0-20.

[pvelesko]

Related chipStar issue: CHIP-SPV/chipStar#1223

[kgibala]

Hi @pvelesko,

Thank you for your contribution.

Before we proceed further, we would like to kindly ask how this GitHub issue ticket was created. We have recently introduced new issue templates to help streamline and standardize the reporting process. Upon reviewing the submitted ticket, it appears that the appropriate template was not used.

As outlined in our Issue Submission Guide, this type of problem should be reported using the [Bug Report] Linux GPU Driver Issue template.

Could you please let us know whether you were aware of these templates or if there were any difficulties accessing them? Your feedback is valuable, as we are continuously working to improve the project and the overall contributor experience.

Thank you for your understanding and cooperation.

[pvelesko]

@kgibala I use gh so I was not aware of new the new template.
I will use the template in the future. do you need me to reword this issue based on the template?

[kgibala]

Hi @pvelesko,

Thank you for the clarification, everything is now clear on our end.

This ticket will be dispatched to the appropriate team for further handling, so no additional action is required from your side at this time.

For future reference, we kindly ask that you use the official GitHub issue templates when submitting new reports, as they help us process and route issues more efficiently.

We appreciate your cooperation and thank you for contributing to the project.