From mboxrd@z Thu Jan 1 00:00:00 1970 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: 7bit 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 --- 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/panthor/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_gpuva_op *op, void *priv) } 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 = to_panthor_bo(op->gem.obj); + struct panthor_gem_object *bo = to_panthor_bo(mapping->gem.obj); + u64 aligned_va = ALIGN_DOWN(va, SZ_2M); const struct page *pg; pgoff_t bo_offset; - bo_offset = 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 = aligned_va - mapping->va.addr + mapping->gem.offset; pg = bo->backing.pages[bo_offset >> PAGE_SHIFT]; + /* 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)) >= SZ_2M; } @@ -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 <= 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 += *unmap_start - aligned_unmap_start; *unmap_start = 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 >= 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 += aligned_unmap_end - unmap_end; } } -- 2.55.0