Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Missing `reset.lock` protection for other hardware-accessing entry points, risking concurrent register access during a GPU reset. -- --- Patch [11]: [PATCH v4 11/13] drm/panfrost: Introduce a reset lock --- commit 37b5ec54907b68f8dbe5d3c8dbd5b539b7f3a90e Author: Adrián Larumbe <[email protected]> drm/panfrost: Introduce a reset lock This commit introduces a read/write semaphore to prevent driver entry points from accessing hardware registers while a reset is ongoing. It wraps the timestamp query ioctl with this lock to avoid races during GPU soft resets. > drm/panfrost: Introduce a reset lock > > So as to avoid accessing HW register while a reset is ongoing, a read/write > semaphore that envelopes the reset sequence will help driver entry points > avoid racing with it. For now, the only such racy entry point is the ioctl > that returns the current GPU timestmap. [Severity: High] This isn't a bug introduced by this patch, but are there other entry points that also race with GPU resets by writing to hardware registers? For instance, panfrost_ioctl_perfcnt_enable() calls panfrost_perfcnt_enable_locked() which writes directly to GPU_CMD: drivers/gpu/drm/panfrost/panfrost_perfcnt.c:panfrost_perfcnt_enable_locked() { ... gpu_write(pfdev, GPU_CMD, GPU_CMD_PERFCNT_CLEAR); gpu_write(pfdev, GPU_CMD, GPU_CMD_CLEAN_INV_CACHES); ... } panfrost_ioctl_perfcnt_dump() and mmu_hw_do_operation() also write to hardware registers (GPU_CMD and AS_COMMAND respectively) without acquiring reset.lock. Could these be invoked concurrently with a job timeout reset? If so, should they also acquire pfdev->reset.lock to prevent hardware state corruption? -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=11
