Re: [PATCH 1/6] accel/qaic: Centralize execution info

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] mm: unaligned memory access in exec.resize_arr array allocation
- [Medium] drm/qaic: failure to deduplicate resv pointers causes -EALREADY
--

commit 564e37a5c5a191292a9c140ea89ad4c33346feeb
Author: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com>
accel/qaic: Centralize execution info

This commit moves per-exec ioctl information into a common data structure
to prepare for adding dma-resv fences, which require all buffer objects
associated with a fence to be locked using drm_gem_lock_reservations.

[Severity: Medium]
In drivers/accel/qaic/qaic_data.c, the function __qaic_execute_bo_ioctl
calculates the offset for exec.resize_arr around line 1502. The driver
allocates a single buffer for three arrays: bo_arr at 8 bytes per element,
handle_arr at 4 bytes per element, and resize_arr at 8 bytes per element.
The offset for resize_arr is calculated as (8 + 4) * count.

If count is an odd number, for example 1, the byte offset becomes an odd
multiple of 12, resulting in a 4-byte aligned pointer. When this is later
written to in lookup_exec_data around line 1426, it performs an unaligned
64-bit memory access. 

Can this lead to alignment faults on platforms with strict alignment
enforcement, or trigger undefined C behavior? Would reordering the array
layout or padding the calculation prevent this regression?

[Severity: Medium]
Also in drivers/accel/qaic/qaic_data.c, the function send_bo_list_to_device
calls drm_gem_lock_reservations directly on the raw, non-deduplicated
exec->bo_arr array around line 1280.

What happens if userspace submits distinct imported buffer objects that
share the same dma_resv pointer, such as from identical or shared dma-bufs?
It appears this attempts to lock the same reservation multiple times within
the same ww_acquire_ctx, causing the underlying ww_mutex to return -EALREADY
and fail the ioctl.

Since the driver previously used a per-BO mutex for locking that allowed
executing distinct BOs with shared reservations, does this code need to
deduplicate the reservation pointers before passing them to the locking
helper to avoid this regression?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261003023818.1161666-1-carl.vanderlip@oss.qualcomm.com?part=1