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 A274938F25D for ; Tue, 7 Apr 2026 07:00:12 +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=1775545223; cv=none; b=BAzej4GzS+/LK3c/ETIBtv/8rSD4hPufksxU6QOLcpI6Igh4h4DdenIpagkjMZ5LCTUWgQkNF4rLTK3IkHmwLsYdmuOwWoBZKYjlib5GWtmy5t6mAkUcKgpQd59AXXj4beyJt9rLePj2CSe+ZbYJfla3mM/FKleIMcUuz3nA5WY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775545223; c=relaxed/simple; bh=EsmCJyDsmm+Rjnz6B0Osuziqt5xz1oUh1j+zEEv/eX0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uK9+xXlmI675RnOq11nLiubSE+t2FIUzucE3L0xpUSW27SZrDA4r6CzHMSTOmro86cadgZTBDaiGPeZmjS5/lA4oNUPs3aFxZFGyLxtYzmQPOh5O3v99kW6fjmNfmt7LsIjeWH1o8Pj4DrT010OqgCr2uC6xz/4Yv6auRbfeCHk= 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=S86zVSCP; 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="S86zVSCP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1775544872; bh=EsmCJyDsmm+Rjnz6B0Osuziqt5xz1oUh1j+zEEv/eX0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=S86zVSCPsxujoEfRrgEEPR0eZZ18k88kAOOJAftVE5uSy/5kKdO5CbtJvaOCsKlyk CUeXC7IUBNpjZxi4lSuha3tGsX9hWZA/OIh1G6lS8TEPPDouyYlxmgS2Ht1YRbYIvO OX6Bz6jJGTv373OfS9DDqOrucuttRI+/TjdavTfkKJSeZRppH/PAK4j2lCtRktZ/6r o3tW+ztgjcwKahtfu/UlSLb6ibcr4wnpIBjwu544gTWivfkwR7DQAamZ1I8Y1VhM1I Q/zgx8AsdR+iUjNkB2OVRt7GSs6GbcHbTXtQLRSml9AYnx8Vayf/gXXzoyciqvAEbP 47oCYhX4Z/zWg== Received: from fedora (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id BB84017E1078; Tue, 7 Apr 2026 08:54:31 +0200 (CEST) Date: Tue, 7 Apr 2026 08:54:26 +0200 From: Boris Brezillon To: =?UTF-8?B?QWRyacOhbg==?= Larumbe Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Steven Price , kernel@collabora.com, Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter Subject: Re: [PATCH 1/2] drm/panthor: Extend VM locked region for remap case to be a superset Message-ID: <20260407085426.26fa3a1e@fedora> In-Reply-To: <20260403172116.3424075-1-adrian.larumbe@collabora.com> References: <20260403172116.3424075-1-adrian.larumbe@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) 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 On Fri, 3 Apr 2026 18:21:11 +0100 Adri=C3=A1n Larumbe wrote: > In the event of an sm_step_remap() that leads to a partial unmap of a > transparent huge page, the new locked region required by an extended unmap > might not be a superset of the original one. Then, if it leaves a portion > of the initially requested one out, the ensuing map will trigger a warnin= g. >=20 > Signed-off-by: Adri=C3=A1n Larumbe > Fixes: 8e7460eac786 ("drm/panthor: Support partial unmaps of huge pages") Reviewed-by: Boris Brezillon One suggestion below. > --- > drivers/gpu/drm/panthor/panthor_mmu.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) >=20 > diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/pant= hor/panthor_mmu.c > index fa8b31df85c9..2b96359d3b94 100644 > --- a/drivers/gpu/drm/panthor/panthor_mmu.c > +++ b/drivers/gpu/drm/panthor/panthor_mmu.c > @@ -1709,6 +1709,19 @@ static int panthor_vm_lock_region(struct panthor_v= m *vm, u64 start, u64 size) > start + size <=3D vm->locked_region.start + vm->locked_region.size) > return 0; > =20 > + /* sm_step_remap() may need a locked region that isn't a strict superset > + * of the original one because of having to extend unmap boundaries bey= ond > + * it to deal with partial unmaps of transparent huge pages. What we wa= nt > + * in those cases is to lock the union of both regions. > + */ > + if (vm->locked_region.size) { > + u64 end =3D start + size; > + > + start =3D min(start, vm->locked_region.start); > + size =3D max(vm->locked_region.start + > + vm->locked_region.size, end) - start; I'd probably go: u64 end =3D max(vm->locked_region.start + vm->locked_region.size, start + size); start =3D min(start, vm->locked_region.start); size =3D end - start; > + } > + > mutex_lock(&ptdev->mmu->as.slots_lock); > if (vm->as.id >=3D 0 && size) { > /* Lock the region that needs to be updated */ >=20 > base-commit: fb42964e2a76f68a5fb581d382b5d2be2d5bda9b