linux-kernel - Re: [PATCH v2] drm/msm: make sure last

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f99f1fcb-2352-42eb-94b8-c7efa497caa2@gmail.com>
Date: Sat, 11 Oct 2025 15:48:08 +0200
From: Anna Maniscalco <anna.maniscalco2000@...il.com>
To: Alexey Minnekhanov <alexeymin@...tmarketos.org>,
 Rob Clark <robin.clark@....qualcomm.com>, Dmitry Baryshkov
 <lumag@...nel.org>, Abhinav Kumar <abhinav.kumar@...ux.dev>,
 Jessica Zhang <jessica.zhang@....qualcomm.com>, Sean Paul <sean@...rly.run>,
 Marijn Suijten <marijn.suijten@...ainline.org>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Antonino Maniscalco <antomani103@...il.com>
Cc: linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] drm/msm: make sure last_fence is always updated

On 10/10/25 9:09 PM, Alexey Minnekhanov wrote:
> On 10.10.2025 17:39, Anna Maniscalco wrote:
>> Update last_fence in the vm-bind path instead of kernel managed path.
>>
>> last_fence is used to wait for work to finish in vm_bind contexts but 
>> not
>> used for kernel managed contexts.
>>
>> This fixes a bug where last_fence is not waited on context close leading
>> to faults as resources are freed while in use.
>>
>> Fixes: 92395af63a99 ("drm/msm: Add VM_BIND submitqueue")
>> ---
>> Signed-off-by: Anna Maniscalco <anna.maniscalco2000@...il.com>
>> ---
>> Changes in v2:
>> - Only update last_fence on vm_bind path
>> - Link to v1: 
>> https://lore.kernel.org/r/20251010-close_fence_wait_fix-v1-1-fd3e394dcadd@gmail.com
>> ---
>>   drivers/gpu/drm/msm/msm_gem_submit.c | 9 +++++----
>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
>> b/drivers/gpu/drm/msm/msm_gem_submit.c
>> index 
>> 3ab3b27134f93b01236fec5833a18a6e2ad2cf5e..75d9f357437006ff261db148901e176eae670d41 
>> 100644
>> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
>> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
>> @@ -414,6 +414,11 @@ static void submit_attach_object_fences(struct 
>> msm_gem_submit *submit)
>>                        submit->user_fence,
>>                        DMA_RESV_USAGE_BOOKKEEP,
>>                        DMA_RESV_USAGE_BOOKKEEP);
>> +
>> +        last_fence = vm->last_fence;
>> +        vm->last_fence = dma_fence_unwrap_merge(submit->user_fence, 
>> last_fence);
>> +        dma_fence_put(last_fence);
>> +
>>           return;
>>       }
>>   @@ -427,10 +432,6 @@ static void submit_attach_object_fences(struct 
>> msm_gem_submit *submit)
>>               dma_resv_add_fence(obj->resv, submit->user_fence,
>>                          DMA_RESV_USAGE_READ);
>>       }
>> -
>> -    last_fence = vm->last_fence;
>> -    vm->last_fence = dma_fence_unwrap_merge(submit->user_fence, 
>> last_fence);
>> -    dma_fence_put(last_fence);
>>   }
>>     static int submit_bo(struct msm_gem_submit *submit, uint32_t idx,
>>
>> ---
>> base-commit: b5bad77e1e3c7249e4c0c88f98477e1ee7669b63
>> change-id: 20251009-close_fence_wait_fix-00e1c2521eee
>>
>> Best regards,
>
> Hi!
>
> Since 6.17 I'm seeing gpu faults that were not present in 6.16, they
> look like [1].
>
> I was hoping this patch can fix it, because faults go away if I comment
> out put_iova_spaces() inside msm_gem_close(), and this patch mentions
> close path and faults together, ... but no. Perhaps something else is
> wrong somewhere?
>
> [1] https://paste.sr.ht/~minlexx/09a9b3d4bfff3e7be3e96cd88fe8cf34621cb655
>
> -- 
> Regards,
> Alexey Minnekhanov
>
If that fault appears when closing applications (which sounds likely 
given your workaround) then yes, this is very much the kind of fault 
this patch intends to fix.

Might be worth a try with this patch to see if it helps with your case.

Best regards,
-- 
Anna Maniscalco <anna.maniscalco2000@...il.com>