Hi,
On Thu, Jul 14, 2022 at 12:31:43PM +0200, Lucas Stach wrote:
> When a idle BO, which is held open by another process, gets freed by
> userspace and subsequently referenced again by e.g. importing it again,
> userspace may assign a different softpin VA than the last time around.
> As the kernel GEM object still exists, we likely have a idle mapping
> with the old VA still cached, if it hasn't been reaped in the meantime.
>
> As the context matches, we then simply try to resurrect this mapping by
> increasing the refcount. As the VA in this mapping does not match the
> new softpin address, we consequently fail the otherwise valid submit.
> Instead of failing, reap the idle mapping.
>
> Cc: stable@xxxxxxxxxxxxxxx # 5.19
> Signed-off-by: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index cc386f8a7116..5cf13e52f7c9 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -258,7 +258,12 @@ struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
> if (mapping->use == 0) {
> mutex_lock(&mmu_context->lock);
> if (mapping->context == mmu_context)
> - mapping->use += 1;
> + if (va && mapping->iova != va) {
> + etnaviv_iommu_reap_mapping(mapping);
> + mapping = NULL;
> + } else {
> + mapping->use += 1;
> + }
> else
> mapping = NULL;
> mutex_unlock(&mmu_context->lock);
Reviewed-by: Guido Günther <agx@xxxxxxxxxxx>
Cheers,
-- Guido
> --
> 2.30.2
>
