From nobody Fri Sep 25 02:43:32 2026 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 E18344E1C73 for ; Thu, 17 Sep 2026 12:33:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789648450; cv=none; b=mSzZf8HgdLH3PdrXPQUgSphwV+ronXOvXLIIiAjW64UGHnjyuF3EyWT8kOuBhVwX6Ws9TSLk7KcGE+1HuOoXZjtci7y0xFXvmTNzhatlJfH+QSJthX75gFIXD8I9iHy2rSdLDrgTsUr6SXIrF9Y5jJjW3gMhPN6R81/dK4sqbYs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789648450; c=relaxed/simple; bh=JeE7JSuO5/PJ0ZMUTphbSHVFgspwYWBLPaeJwLbCYsU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=caF+wU/3g0/oDi9xbWuTzzGp7qpRZpkAyvouk+F5DNMMhwmhKfaoAUDR5ZevWu6a799AdcYm+DDozS7aDwVcxHCfGcTjayz02AI0cRvX2D1FU8tG6yxPveH7IydBwiFgulUHnRLl8Hbu5wYxpfSLoPm2CPE5lu1BsrF90qyZf28= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none 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=ULFOSIKb; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none 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="ULFOSIKb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1789648435; bh=JeE7JSuO5/PJ0ZMUTphbSHVFgspwYWBLPaeJwLbCYsU=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=ULFOSIKbsrko4F3FTkqwavaF/ildILVjscSw+5WroSP4mzXOv6TAulOfqNhQ/mtwh noA9NWPNoKwX6XzQP/0lNAmfjkJSvvJDMY4IOgjjcfUkv4p+KTgCWfmHzAA+FJ3+Ul 8caBF16l/4L9t1X0DCg3RYW9HCS104Vxyxt6tSNPq2ZUxZo4E0eWI+8byO1wU2L/s0 +RJnTckUS66ZDbpdqvw8NMfEmFdgS7E0Sbng1ZcnKrTYQFstclMn617uHdjzsm2tU2 hsnSALFBLjAD2xgIDYj/DnUN+6+R7aNTJ9PRY3sJ8iuUR+Ywa8yIIDzJfRW4QvfByS L8bpwTwg+23pA== Received: from fedora-21.home (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id C390D17E0C7E; Thu, 17 Sep 2026 14:33:54 +0200 (CEST) From: Boris Brezillon Date: Thu, 17 Sep 2026 14:33:43 +0200 Subject: [PATCH 1/4] drm/panthor: Avoid false positives in iova_mapped_as_huge_page() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260917-panthor-fix-partial-unmap-v1-1-c7008f15fea3@collabora.com> References: <20260917-panthor-fix-partial-unmap-v1-0-c7008f15fea3@collabora.com> In-Reply-To: <20260917-panthor-fix-partial-unmap-v1-0-c7008f15fea3@collabora.com> To: Steven Price , Liviu Dudau , =?utf-8?q?Adri=C3=A1n_Larumbe?= , Akash Goel Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Boris Brezillon X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789648434; l=3538; i=boris.brezillon@collabora.com; s=20260429; h=from:subject:message-id; bh=JeE7JSuO5/PJ0ZMUTphbSHVFgspwYWBLPaeJwLbCYsU=; b=wGPgQEwelskuc+lgj7kWNWjVNyFvfecrBCYufa5vvhzqTKH4bSrQS1ZBavi6UlpBqhybW8/8b aTf36urAxk+CCQBkEkTEl0rOOHfVQgSGtP6IHIlzw9DdPEDP5H2lvYt X-Developer-Key: i=boris.brezillon@collabora.com; a=ed25519; pk=eN+ORdOgQY7d5U+0kA8h5bf67XdD8bhKbjD/TCHexSY= The check on the folio size is actually moot if the BO offset matching the VA we're checking huge-mapping for is not 2M aligned as well. This means that we are sometimes returning true when we shouldn't, which forces an extra unmap+map to deal with block-mapping splits. It's not a functional bug per-se, because the unmap+map sequence will restore things in the state we expect them to be, but it's better to properly optimize those cases. Note that we now align the VA on 2M address below it otherwise we can't check the bo_offset alignment (both physical and virtual address need to be aligned, in addition to the physically contiguous size being 2M, which the folio size check ensures). These changes force us to pass the drm_gpuva that's being unmapped instead of the new mappings that will be created to cover the left/right sections we remap. This changes makes the logic a lot easier to reason about, because it doesn't make sense to how things were mapped by passing the new mappings that are not yet in place. Fixes: 8e7460eac786 ("drm/panthor: Support partial unmaps of huge pages") Signed-off-by: Boris Brezillon Reviewed-by: Akash Goel Reviewed-by: Liviu Dudau --- drivers/gpu/drm/panthor/panthor_mmu.c | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/pantho= r/panthor_mmu.c index 9f63a048df61..b0a7033480e6 100644 --- a/drivers/gpu/drm/panthor/panthor_mmu.c +++ b/drivers/gpu/drm/panthor/panthor_mmu.c @@ -2295,15 +2295,29 @@ static int panthor_gpuva_sm_step_map(struct drm_gpu= va_op *op, void *priv) } =20 static bool -iova_mapped_as_huge_page(struct drm_gpuva_op_map *op, u64 addr) +iova_mapped_as_huge_page(struct drm_gpuva *mapping, u64 va) { - struct panthor_gem_object *bo =3D to_panthor_bo(op->gem.obj); + struct panthor_gem_object *bo =3D to_panthor_bo(mapping->gem.obj); + u64 aligned_va =3D ALIGN_DOWN(va, SZ_2M); const struct page *pg; pgoff_t bo_offset; =20 - bo_offset =3D addr - op->va.addr + op->gem.offset; + /* If the 2M-aligned VA is outside the mapping being tested, we know + * it's not a huge map. + */ + if (aligned_va < mapping->va.addr) + return false; + + bo_offset =3D aligned_va - mapping->va.addr + mapping->gem.offset; pg =3D bo->backing.pages[bo_offset >> PAGE_SHIFT]; =20 + /* In case of shmem backing, we know we can only have a huge mapping + * if the bo_offset is 2M aligned, meaning we can skip the folio size + * check if it's not the case. + */ + if (!IS_ALIGNED(bo_offset, SZ_2M)) + return false; + return folio_size(page_folio(pg)) >=3D SZ_2M; } =20 @@ -2328,7 +2342,7 @@ unmap_hugepage_align(const struct drm_gpuva_op_remap = *op, */ if (op->prev && aligned_unmap_start < *unmap_start && op->prev->va.addr <=3D aligned_unmap_start && - (is_sparse || iova_mapped_as_huge_page(op->prev, *unmap_start))) { + (is_sparse || iova_mapped_as_huge_page(op->unmap->va, *unmap_start)))= { *unmap_range +=3D *unmap_start - aligned_unmap_start; *unmap_start =3D aligned_unmap_start; } @@ -2338,7 +2352,7 @@ unmap_hugepage_align(const struct drm_gpuva_op_remap = *op, */ if (op->next && aligned_unmap_end > unmap_end && op->next->va.addr + op->next->va.range >=3D aligned_unmap_end && - (is_sparse || iova_mapped_as_huge_page(op->next, unmap_end - 1))) { + (is_sparse || iova_mapped_as_huge_page(op->unmap->va, unmap_end - 1))= ) { *unmap_range +=3D aligned_unmap_end - unmap_end; } } --=20 2.55.0 From nobody Fri Sep 25 02:43:32 2026 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 08C2C4D5978 for ; Thu, 17 Sep 2026 12:33:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789648446; cv=none; b=SwYLNRkxM3N7ldtbzhLNSEbaZH5eiRMtOACodTQn30aNTrlFkaAFMFTT2Uhfb2664hEzRB7yBlPtf1V1h43vwc38WC441b0BC1KRuE90YDX8Kik1Em2ZrS1yxqtDsZNl3h5EWg+iDbHPMqxM13TQUxNjCHMl24C1qvDSNCCMaOc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789648446; c=relaxed/simple; bh=+/6KEJbBTvcP3lAfbZbBakogb+HfHH7iLFVHHmk1YoU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=qhW2DPeS4vU+Y9cLtgjLJ6jARUfL3zXdLJL9y7wa8+ZfRTRR57YvNm/aR16c10oEgJuSBOhhdjNLI6tZX8hAt6McBliHw98dmOxo3WbDiTu+oUIrmLmb0pqWSiAZ2WBOEVtEmOCAP4dLpQhjrtUBgC1ScrH/5cW3kF4b99Hm2+w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none 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=gUIhr/FC; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none 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="gUIhr/FC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1789648435; bh=+/6KEJbBTvcP3lAfbZbBakogb+HfHH7iLFVHHmk1YoU=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=gUIhr/FC9+Cl5DFVzrJYVeO0JcJTA1T15TJvK8x3B0FWu5TUhOi8IVS0kUX1yhuHB 6SVYGKPWW0GYnUAGKeMipVbSVau3gkC2yaXkoz268wud29FJuGKydD6OIoRQrwPSYW sQ17H4tEdlERTIRpl25zU+EBvIbXvuMJ8rdnltKrEzPTHK+3hBDmi1d22Fia7odM3r 1b/xvYMQmoXmMRWnI9aVbzJM6uLHl+OUHoL3pfMae0RRP1XgCSE1cqMEabeMlKBjRQ 00/WRAVFXLVP0Mo96sfzoN+ZBW9d9XTUdwLk9/K8qIKlyVypwjxy6JOB+OHeyjBmDR 8G247a+Xro7MA== Received: from fedora-21.home (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 636D017E0CFC; Thu, 17 Sep 2026 14:33:55 +0200 (CEST) From: Boris Brezillon Date: Thu, 17 Sep 2026 14:33:44 +0200 Subject: [PATCH 2/4] drm/panthor: Fix iova_mapped_as_huge_page() for imported BOs Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260917-panthor-fix-partial-unmap-v1-2-c7008f15fea3@collabora.com> References: <20260917-panthor-fix-partial-unmap-v1-0-c7008f15fea3@collabora.com> In-Reply-To: <20260917-panthor-fix-partial-unmap-v1-0-c7008f15fea3@collabora.com> To: Steven Price , Liviu Dudau , =?utf-8?q?Adri=C3=A1n_Larumbe?= , Akash Goel Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Boris Brezillon X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789648434; l=2952; i=boris.brezillon@collabora.com; s=20260429; h=from:subject:message-id; bh=+/6KEJbBTvcP3lAfbZbBakogb+HfHH7iLFVHHmk1YoU=; b=/6f0RvsmRgtCwqThhT/PPj2gaRskYBI2YfE6ievX8O1cQq6L4EofKhrSDQWV+efX7B6Ltird6 +2avVtJSqAeAs4VE14V24hhr/lZWazV7AkFGTiaGW3h0CgmqZ/5R+5Q X-Developer-Key: i=boris.brezillon@collabora.com; a=ed25519; pk=eN+ORdOgQY7d5U+0kA8h5bf67XdD8bhKbjD/TCHexSY= Imported BOs have no backing.pages array allocated, leading to a NULL deref when iova_mapped_as_huge_page() gets called on them. Implement this check through and sgt walk to reach the position of the sgt targeted by a VA, and check that the DMA address is properly aligned and the size remaining in the SG entry is bigger than a huge page. This is basically matching the logic in vm_map_pages(), with get_pgsize() being replaced by a simpler test, because we don't care about the pgcount info. Reported-by: Akash Goel Fixes: 8e7460eac786 ("drm/panthor: Support partial unmaps of huge pages") Signed-off-by: Boris Brezillon Reviewed-by: Akash Goel Reviewed-by: Liviu Dudau --- drivers/gpu/drm/panthor/panthor_mmu.c | 44 ++++++++++++++++++++++++++++---= ---- 1 file changed, 36 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/pantho= r/panthor_mmu.c index b0a7033480e6..6cef954e2cba 100644 --- a/drivers/gpu/drm/panthor/panthor_mmu.c +++ b/drivers/gpu/drm/panthor/panthor_mmu.c @@ -2299,7 +2299,6 @@ iova_mapped_as_huge_page(struct drm_gpuva *mapping, u= 64 va) { struct panthor_gem_object *bo =3D to_panthor_bo(mapping->gem.obj); u64 aligned_va =3D ALIGN_DOWN(va, SZ_2M); - const struct page *pg; pgoff_t bo_offset; =20 /* If the 2M-aligned VA is outside the mapping being tested, we know @@ -2309,16 +2308,45 @@ iova_mapped_as_huge_page(struct drm_gpuva *mapping,= u64 va) return false; =20 bo_offset =3D aligned_va - mapping->va.addr + mapping->gem.offset; - pg =3D bo->backing.pages[bo_offset >> PAGE_SHIFT]; =20 - /* In case of shmem backing, we know we can only have a huge mapping - * if the bo_offset is 2M aligned, meaning we can skip the folio size - * check if it's not the case. - */ - if (!IS_ALIGNED(bo_offset, SZ_2M)) + if (drm_gem_is_imported(&bo->base)) { + struct sg_table *sgt =3D bo->dmap.sgt; + struct scatterlist *sgl; + unsigned int count; + + /* If this is an imported BO, we have to walk the SGT and + * check the dma address/size alignment to determine if it's + * a huge map or not. + */ + for_each_sgtable_dma_sg(sgt, sgl, count) { + size_t len =3D sg_dma_len(sgl); + dma_addr_t daddr; + + if (len <=3D bo_offset) { + bo_offset -=3D len; + continue; + } + + len -=3D bo_offset; + daddr =3D sg_dma_address(sgl) + bo_offset; + + return IS_ALIGNED(daddr, SZ_2M) && + len >=3D SZ_2M; + } + return false; + } else { + const struct page *pg =3D bo->backing.pages[bo_offset >> PAGE_SHIFT]; =20 - return folio_size(page_folio(pg)) >=3D SZ_2M; + /* In case of shmem backing, we know we can only have a huge mapping + * if the bo_offset is 2M aligned, meaning we can skip the folio size + * check if it's not the case. + */ + if (!IS_ALIGNED(bo_offset, SZ_2M)) + return false; + + return folio_size(page_folio(pg)) >=3D SZ_2M; + } } =20 static void --=20 2.55.0 From nobody Fri Sep 25 02:43:32 2026 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 4E1C848CD55 for ; Thu, 17 Sep 2026 12:33:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789648448; cv=none; b=R2F3b9AFcLMsVtcSamMYJXz41Amu/rsm1g9YAk7TdJwKm+SVvvEMUbwT3nMHnwIXOsGPvKDkhvGOCQDmHPCScFYSi6owiLiJub0XLbwl/4483tGfKcyRCSd8TWGL01qu36ju+aEDMwXwJ5l9FOKXgp+Fpz8gOi/aUxwCDC1M43E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789648448; c=relaxed/simple; bh=aJVJGqAxRDrukH3Sf8Wf633FJCiWUOMYXyKmSTk8psc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=qOkfTR//Zv6vfguMAolbl8w3h09uQl4BuvswiNJuQQ4gC5Xv10hzhr7Sx00iV2S90/siRwj59IS/Ufxc6lGC2uV7ajhyR5x+zpJ4TCAv0CLeqnmGYsePVxYFfCAx9cl7wHR2nJX41iRJY5v4lqTYam3+DnpjVQKwVkHWM1yiPQ0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none 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=PMVym+np; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none 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="PMVym+np" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1789648436; bh=aJVJGqAxRDrukH3Sf8Wf633FJCiWUOMYXyKmSTk8psc=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=PMVym+npNkzn/YnoZkk2K045nv22SIaInlPRspHzByEei6WmbA3fpC1ywBnnLWi3z Sd8SbIcXKPmvjz6mB9InzfPzF6E2vYCui7PvURB0XCRvS6t67nj3Ld180sHU3Zplm1 /5HEL3LPulZctjvXmUfCR6TdX6aze0tQ1JpsBH5HsmdGnzAUKDnr7B88IuwnzRxV5J JZtHxdn44SKx2KzkGtZtEYb84Mnc7PAPhdJuyWtuooNBR2eC0ADcMfy/Hlq0tjVf6X hQZzTKa7QQr1Wpee770lL9fvPSCFoJQjSN1bF0ao6vEf0TLUzfCFMBJTRXN8Fsn9pe dICrZt0uFem1Q== Received: from fedora-21.home (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id F297D17E0D43; Thu, 17 Sep 2026 14:33:55 +0200 (CEST) From: Boris Brezillon Date: Thu, 17 Sep 2026 14:33:45 +0200 Subject: [PATCH 3/4] drm/panthor: Consolidate the is-huge-page-mapping test Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260917-panthor-fix-partial-unmap-v1-3-c7008f15fea3@collabora.com> References: <20260917-panthor-fix-partial-unmap-v1-0-c7008f15fea3@collabora.com> In-Reply-To: <20260917-panthor-fix-partial-unmap-v1-0-c7008f15fea3@collabora.com> To: Steven Price , Liviu Dudau , =?utf-8?q?Adri=C3=A1n_Larumbe?= , Akash Goel Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Boris Brezillon X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789648434; l=4892; i=boris.brezillon@collabora.com; s=20260429; h=from:subject:message-id; bh=aJVJGqAxRDrukH3Sf8Wf633FJCiWUOMYXyKmSTk8psc=; b=ZeMKwZBDEOsY/YkZUiqu6zw+QTNEw8GXV/jgm0fdnWGXrJq/+KyIQN/AGkOwdDYTKoG1CQogC fm1/V5LMhlaCfbRcKC0v6G8WqMGnK0kZlT+6jp9w61F98FYYO2vk99P X-Developer-Key: i=boris.brezillon@collabora.com; a=ed25519; pk=eN+ORdOgQY7d5U+0kA8h5bf67XdD8bhKbjD/TCHexSY= Right now the logic to determine whether a given VA in the drm_gpuva being unmapped is a huge page mapping or not is scattered in two functions: unmap_hugepage_align() and iova_mapped_as_huge_page(). This makes it harder to reason about the logic being implemented for very little gain (some simple checks being done twice), so let's consolidate all the checks related to huge page mapping testing in iova_mapped_as_huge_page() and leave unmap_hugepage_align() as a simple user of this helper that aligns the area to unmap based on the return of iova_mapped_as_huge_page(). Signed-off-by: Boris Brezillon Reviewed-by: Akash Goel Reviewed-by: Liviu Dudau --- drivers/gpu/drm/panthor/panthor_mmu.c | 57 +++++++++++++++++--------------= ---- 1 file changed, 28 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/pantho= r/panthor_mmu.c index 6cef954e2cba..d2897099763e 100644 --- a/drivers/gpu/drm/panthor/panthor_mmu.c +++ b/drivers/gpu/drm/panthor/panthor_mmu.c @@ -2301,10 +2301,11 @@ iova_mapped_as_huge_page(struct drm_gpuva *mapping,= u64 va) u64 aligned_va =3D ALIGN_DOWN(va, SZ_2M); pgoff_t bo_offset; =20 - /* If the 2M-aligned VA is outside the mapping being tested, we know - * it's not a huge map. + /* If the 2M section being tested is crossing the mapping boundary + * we know it's not a huge map. */ - if (aligned_va < mapping->va.addr) + if (aligned_va < mapping->va.addr || + aligned_va + SZ_2M > mapping->va.addr + mapping->va.range) return false; =20 bo_offset =3D aligned_va - mapping->va.addr + mapping->gem.offset; @@ -2337,10 +2338,21 @@ iova_mapped_as_huge_page(struct drm_gpuva *mapping,= u64 va) return false; } else { const struct page *pg =3D bo->backing.pages[bo_offset >> PAGE_SHIFT]; + struct panthor_vma *vma =3D container_of(mapping, struct panthor_vma, ba= se); + bool is_sparse =3D vma->flags & DRM_PANTHOR_VM_BIND_OP_MAP_SPARSE; =20 - /* In case of shmem backing, we know we can only have a huge mapping - * if the bo_offset is 2M aligned, meaning we can skip the folio size - * check if it's not the case. + /* If the unmapped VMA stands for a sparse mapping, always + * assume the backing storage is a THP, since the overhead of + * unmapping 2MiB worth of 4KiB pages and remapping some of + * them is offset by the logic of working out whether it's + * the opposite case right below. + */ + if (is_sparse) + return true; + + /* In case of shmem backing, we know we can only have a huge + * mapping if the bo_offset is 2M aligned, meaning we can skip + * the folio size check if it's not the case. */ if (!IS_ALIGNED(bo_offset, SZ_2M)) return false; @@ -2353,36 +2365,23 @@ static void unmap_hugepage_align(const struct drm_gpuva_op_remap *op, u64 *unmap_start, u64 *unmap_range) { - struct panthor_vma *unmap_vma =3D container_of(op->unmap->va, struct pant= hor_vma, base); - bool is_sparse =3D unmap_vma->flags & DRM_PANTHOR_VM_BIND_OP_MAP_SPARSE; - u64 aligned_unmap_start, aligned_unmap_end, unmap_end; - - unmap_end =3D *unmap_start + *unmap_range; - aligned_unmap_start =3D ALIGN_DOWN(*unmap_start, SZ_2M); - aligned_unmap_end =3D ALIGN(unmap_end, SZ_2M); + u64 unmap_end =3D *unmap_start + *unmap_range; =20 /* If we're dealing with a huge page, make sure the unmap region is - * aligned on the start of the page. If the unmapped VMA stands for - * a sparse mapping, always assume the backing storage is a THP, since - * the overhead of unmapping 2MiB worth of 4KiB pages and remapping - * some of them is offset by the logic of working out whether it's - * the opposite case right below. This also holds true for op->next. + * aligned on the start of the page. */ - if (op->prev && aligned_unmap_start < *unmap_start && - op->prev->va.addr <=3D aligned_unmap_start && - (is_sparse || iova_mapped_as_huge_page(op->unmap->va, *unmap_start)))= { - *unmap_range +=3D *unmap_start - aligned_unmap_start; - *unmap_start =3D aligned_unmap_start; - } + if (op->prev && !IS_ALIGNED(*unmap_start, SZ_2M) && + iova_mapped_as_huge_page(op->unmap->va, *unmap_start)) + *unmap_start =3D ALIGN_DOWN(*unmap_start, SZ_2M); =20 /* If we're dealing with a huge page, make sure the unmap region is * aligned on the end of the page. */ - if (op->next && aligned_unmap_end > unmap_end && - op->next->va.addr + op->next->va.range >=3D aligned_unmap_end && - (is_sparse || iova_mapped_as_huge_page(op->unmap->va, unmap_end - 1))= ) { - *unmap_range +=3D aligned_unmap_end - unmap_end; - } + if (op->next && !IS_ALIGNED(unmap_end, SZ_2M) && + iova_mapped_as_huge_page(op->unmap->va, unmap_end - 1)) + unmap_end =3D ALIGN(unmap_end, SZ_2M); + + *unmap_range =3D unmap_end - *unmap_start; } =20 static int panthor_gpuva_sm_step_remap(struct drm_gpuva_op *op, --=20 2.55.0 From nobody Fri Sep 25 02:43:32 2026 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 101654F646A for ; Thu, 17 Sep 2026 12:34:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789648450; cv=none; b=jMbkM/EXKkJX0pNUrpPlQw3RlgVL+lE1CG85CbTm9PQs3Fx2jZ8xX+CL+JjgpDwZHHU15HJb7EQ0hiu+Q6JpbanpayHGlFWNdAOgegxP5zscZsQ3WcpIQW/TuevBe17peVZy4CsoG6hegI/HMe6dLxTZPsYMlsoKF068K59wtrU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789648450; c=relaxed/simple; bh=MMaeeSrGWMieAmAph989GfXw7lO4bxKRBjJxUH/Jb3I=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=qpJHbLH0MfdNFvd+xbOGL9Lq7GWXm/iUUBvjDOMYorb7PK+rN0NN2X3G+5vknFH16W4raNS7YJdSmr1xJJO7lcA4c6OR/PDW/nIsSJ4bqqrywOkccKtmM4T0+xhKhM/Hd1sxRVb2/WRwbc4i26FfL6mOqG5EiqRdj4qFeQ49ZKo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none 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=nqLkagaa; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none 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="nqLkagaa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1789648437; bh=MMaeeSrGWMieAmAph989GfXw7lO4bxKRBjJxUH/Jb3I=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=nqLkagaaq4NpPmOcQQ9dyZHhM8TC5kc1BTKym3/UDIsUjRrtDOV4Pwtn9IasB4nLt xRf42lz44SBfJ5NexowvCRdIKTQXrwUMiORVDaY8i1tSbJNOgf8tMAxu53n4Qq2rGo vl4SerpulB7WdzO+kF3WvUZDkNGi/ZU/fJOnFFeZm4Exbgt7ycXRY4UMCC5vmbIPjA Id6rkFCjpjbyTTdLIrZlTUKx7WEVKa4CcdTj/1Ry6CEQCTES1asbj/C/34WX+dF1iA Z4y+S6f3cU0NzzPiXmq5yvgBiL6Ao3Ah6gmvRUYbFtiA9ez9gIIXmPHFmmgyyUAN/7 M4Iwc22ugTMNQ== Received: from fedora-21.home (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 8DCAC17E0D49; Thu, 17 Sep 2026 14:33:56 +0200 (CEST) From: Boris Brezillon Date: Thu, 17 Sep 2026 14:33:46 +0200 Subject: [PATCH 4/4] drm/panthor: Actually check huge-page mapping on sparse regions Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260917-panthor-fix-partial-unmap-v1-4-c7008f15fea3@collabora.com> References: <20260917-panthor-fix-partial-unmap-v1-0-c7008f15fea3@collabora.com> In-Reply-To: <20260917-panthor-fix-partial-unmap-v1-0-c7008f15fea3@collabora.com> To: Steven Price , Liviu Dudau , =?utf-8?q?Adri=C3=A1n_Larumbe?= , Akash Goel Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Boris Brezillon X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789648434; l=2435; i=boris.brezillon@collabora.com; s=20260429; h=from:subject:message-id; bh=MMaeeSrGWMieAmAph989GfXw7lO4bxKRBjJxUH/Jb3I=; b=OLN2Zp5omrp5SZzdpvBzuDGCa2LsqTMYPovhSI3WaSrgTUG4x4Ym2O3HQ/aWq7xLzq5gxCVOq K+tS5PYmUQiBOnQ8Kf8Ksk+Pz53cVbKM6+Se47Wng4W7XA8ur45GYyJ X-Developer-Key: i=boris.brezillon@collabora.com; a=ed25519; pk=eN+ORdOgQY7d5U+0kA8h5bf67XdD8bhKbjD/TCHexSY= With the recent changes to iova_mapped_as_huge_page(), the check for huge-page mapping of sparse BOs is actually simple: - for a sparse mapping, we know the BO offset any VA in this regions is va & (SZ_2M - 1) - the VA we're searching the BO offset for is the 2M-aligned aligned_va value This guarantees that the BO offset to check is always zero in that case. This is simple enough to let the code check if page 0 is a huge page and save the unmap+map dance when the dummy BO is not backed by a a huge page. So let's do that and kill the comment that says it's too complicated. Signed-off-by: Boris Brezillon Reviewed-by: Akash Goel Reviewed-by: Liviu Dudau --- drivers/gpu/drm/panthor/panthor_mmu.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/pantho= r/panthor_mmu.c index d2897099763e..01564d250adf 100644 --- a/drivers/gpu/drm/panthor/panthor_mmu.c +++ b/drivers/gpu/drm/panthor/panthor_mmu.c @@ -2337,18 +2337,18 @@ iova_mapped_as_huge_page(struct drm_gpuva *mapping,= u64 va) =20 return false; } else { - const struct page *pg =3D bo->backing.pages[bo_offset >> PAGE_SHIFT]; struct panthor_vma *vma =3D container_of(mapping, struct panthor_vma, ba= se); bool is_sparse =3D vma->flags & DRM_PANTHOR_VM_BIND_OP_MAP_SPARSE; + const struct page *pg; =20 - /* If the unmapped VMA stands for a sparse mapping, always - * assume the backing storage is a THP, since the overhead of - * unmapping 2MiB worth of 4KiB pages and remapping some of - * them is offset by the logic of working out whether it's - * the opposite case right below. + /* BO offset on a sparse mapping is chosen so that 2M-aligned + * VAs point to the start of the BO. Since aligned_va (the + * address we check huge-page against) is 2M-aligned, the BO + * offset is guaranteed to be zero. + * Check panthor_fix_sparse_map_offset() for more details. */ if (is_sparse) - return true; + bo_offset =3D 0; =20 /* In case of shmem backing, we know we can only have a huge * mapping if the bo_offset is 2M aligned, meaning we can skip @@ -2357,6 +2357,7 @@ iova_mapped_as_huge_page(struct drm_gpuva *mapping, u= 64 va) if (!IS_ALIGNED(bo_offset, SZ_2M)) return false; =20 + pg =3D bo->backing.pages[bo_offset >> PAGE_SHIFT]; return folio_size(page_folio(pg)) >=3D SZ_2M; } } --=20 2.55.0