From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from madrid.collaboradmins.com (madrid.collaboradmins.com [46.235.227.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D77A11D547 for ; Thu, 4 Apr 2024 15:23:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=46.235.227.194 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712244236; cv=none; b=j8yzZge4WyCK2AjaWJ3QxvOnKNe5D7gugSbi+kF5Aj9HLbs24QOlLDSft/A40Qh+HgwP0ouT1IkO6BhyDTT15J37U+VBy2Q7ASdX0MTw17Nz3n/3l0MKsaOvH8ARZqyko6Bt/HpD2u2x52ERrmjfvLa3+avaG26s+tE5Y/S1MvY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712244236; c=relaxed/simple; bh=zfakYO7CS29y5adFO9lRm1TfVsKhvUUh8TJ3RmzDees=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=S7y9SPs/YWexamHRVczvKllfX6OYrdOZ3c6BOAxri02/2QfWLqRS6pcko0WnZ8K97GUXpyNtm/S44jRQH5eOLRj8Jr10FUbHaZaYFMRud329rGVXqbuzCQXzDqXGbBfaXABMSJn1AVt7iwMvvR8ZDNzSwlmPBvuLg2SfyrvpVlo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=bTFCO1zG; arc=none smtp.client-ip=46.235.227.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="bTFCO1zG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1712244233; bh=zfakYO7CS29y5adFO9lRm1TfVsKhvUUh8TJ3RmzDees=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=bTFCO1zGGbjB8onR6iZ4lBCNh9FODnJT9hBCwn4S/byXbNgUKQM9toMO9XrndQ0sn qN1C3bs0FtXvkvghDMLs4VoksoBiBAdoEi8z8S/ZHKoP0zHcK01EtlLnzRB6B46GxZ y9YZW4dA7xN6p2plCxTlDcQiNDOwEA/g5h8QgxHimdtOHgbwwcOoH6XYmoHVp7VOiq zz+qjkcJTgYrcWfk1bUp05IVfCu+m0j3MQ/vFojMOFoDUFfVjDNuAKLDIcYaJOZni4 H8YIyU88BGwX6iL83kGnIL6tcagzZMEJUuUcMppg8pxiGQIvXIK+ddTGr8/sJfarmJ ySE3ee9VaUySQ== Received: from [100.109.49.129] (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dmitry.osipenko) by madrid.collaboradmins.com (Postfix) with ESMTPSA id B892D37813A4; Thu, 4 Apr 2024 15:23:51 +0000 (UTC) Message-ID: <1f23ab7a-334c-4d7d-b917-8e8029e6c690@collabora.com> Date: Thu, 4 Apr 2024 18:23:49 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v19 17/30] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr() From: Dmitry Osipenko To: Steven Price , Boris Brezillon Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, kernel@collabora.com, virtualization@lists.linux-foundation.org, David Airlie , Gerd Hoffmann , Gurchetan Singh , Chia-I Wu , Daniel Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , =?UTF-8?Q?Christian_K=C3=B6nig?= , Qiang Yu , Emma Anholt , Melissa Wen References: <20240105184624.508603-1-dmitry.osipenko@collabora.com> <20240105184624.508603-18-dmitry.osipenko@collabora.com> Content-Language: en-US In-Reply-To: <20240105184624.508603-18-dmitry.osipenko@collabora.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/5/24 21:46, Dmitry Osipenko wrote: > From: Boris Brezillon > > If some the pages or sgt allocation failed, we shouldn't release the > pages ref we got earlier, otherwise we will end up with unbalanced > get/put_pages() calls. We should instead leave everything in place > and let the BO release function deal with extra cleanup when the object > is destroyed, or let the fault handler try again next time it's called. > > Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") > Cc: > Signed-off-by: Boris Brezillon > Co-developed-by: Dmitry Osipenko > Signed-off-by: Dmitry Osipenko > --- > drivers/gpu/drm/panfrost/panfrost_mmu.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c b/drivers/gpu/drm/panfrost/panfrost_mmu.c > index bd5a0073009d..4a0b4bf03f1a 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c > +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c > @@ -502,11 +502,18 @@ static int panfrost_mmu_map_fault_addr(struct panfrost_device *pfdev, int as, > mapping_set_unevictable(mapping); > > for (i = page_offset; i < page_offset + NUM_FAULT_PAGES; i++) { > + /* Can happen if the last fault only partially filled this > + * section of the pages array before failing. In that case > + * we skip already filled pages. > + */ > + if (pages[i]) > + continue; > + > pages[i] = shmem_read_mapping_page(mapping, i); > if (IS_ERR(pages[i])) { > ret = PTR_ERR(pages[i]); > pages[i] = NULL; > - goto err_pages; > + goto err_unlock; > } > } > > @@ -514,7 +521,7 @@ static int panfrost_mmu_map_fault_addr(struct panfrost_device *pfdev, int as, > ret = sg_alloc_table_from_pages(sgt, pages + page_offset, > NUM_FAULT_PAGES, 0, SZ_2M, GFP_KERNEL); > if (ret) > - goto err_pages; > + goto err_unlock; > > ret = dma_map_sgtable(pfdev->dev, sgt, DMA_BIDIRECTIONAL, 0); > if (ret) > @@ -537,8 +544,6 @@ static int panfrost_mmu_map_fault_addr(struct panfrost_device *pfdev, int as, > > err_map: > sg_free_table(sgt); > -err_pages: > - drm_gem_shmem_put_pages_locked(&bo->base); > err_unlock: > dma_resv_unlock(obj->resv); > err_bo: Applied to misc-fixes Forgot that this patch doesn't depend on others in this series, sorry for not doing it earlier -- Best regards, Dmitry