Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [Critical] On failure to allocate a child request in multi_lrc_nop_request(), the already-submitted parent request (and possibly some child requests) are abandoned without waiting for them to complete. This leads to a Use-After-Free when the parent context is unpinned and freed by the caller. -- commit 5b7b11cc22424a0209d44bac64a471f684e9959f Author: Linmao Li <[email protected]> drm/i915/guc: Sort multi-lrc engines by logical instance This commit replaces a custom logical sorting loop with the standard sort() function for multi-lrc engines. This fixes potential out-of-bounds stack accesses and corrects the sorting logic to copy pointers rather than the engine structure data. > diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c > b/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c > index 28e8a092f4e7d..b56768d202b06 100644 > --- a/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c > +++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c [ ... ] While reviewing this code, I noticed a pre-existing issue in the same file: drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c:multi_lrc_nop_request() > child_rq = intel_context_create_request(child); > if (IS_ERR(child_rq)) > goto child_error; [Severity: Critical] This is a pre-existing issue, but does this error path leave earlier parent or child requests in flight without waiting for them to complete? If so, when the caller __intel_guc_multi_lrc_basic() receives this error: drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c:__intel_guc_multi_lrc_basic() > out: > multi_lrc_context_unpin(parent); > multi_lrc_context_put(parent); Could this lead to a use-after-free? The caller forces the unpin and drops the final creation reference to the context while the stranded in-flight requests still hold dangling pointers to it. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
