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 890FF24E4A1 for ; Wed, 17 Jun 2026 18:50:11 +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=1781722213; cv=none; b=gB0O+XTRo1EsGBBREihnKjB57cnL6mpde90KI1CBRMDNun2UY0SoXmQQDe8FdVN6NMIUZZvw1WqQp67f1v50kqvaHiZ7Vvgln8m5+HIRwiBtnfnvwTgr23SCSn/8aAI4sjpFM8V53aNmQvEDV3ZcTePG5QBiUxr+rauaM+xplGg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781722213; c=relaxed/simple; bh=JqP6Ayxchnt99lpk4hwCZubTHdcg/oCBzU2SiXZ3Buw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=V+gG/xLXwlUaKRGLnang/DwsgKRhsWnioOtVyN7SbF5+LceLvqgOAnTEY4Vy4jYFkT75wokKo/wBXFPV2Epgy9wkVFKmi29t4kaP2IJJZyLDv4LY/aq4Ztw+hVHHK19Ou5zPzk1Zspxs6PufNqO/zW91AhXLnmOnbk1+NLmwY84= 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=Om7EQosq; 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="Om7EQosq" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1781722209; bh=JqP6Ayxchnt99lpk4hwCZubTHdcg/oCBzU2SiXZ3Buw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Om7EQosqRrO6ZmzekHj4urgFzcoU1TY7OJh+gT76fqbsDekF+prX2xy91Qf6d9h77 yZ/wB5HdauS3pDabLZR8kONDq6UOKscJ/JHdnQt7a1tToq/AHeJFAeNQmIZcNbK7XB QrwQc71D5rwz8U6qjwzMRWT4l7OsZhGRvxy4LwHgXP9guukQURxy1QK5+PM1pYT+G/ X25nssCrfy1XfudZ0jM+IA5rXpJ7wS5FEP3VW8heL6ChgvJkid0S/XDBfRpefw3LGy pTztS+jzQH8tETXRdZU6M6scJ4VK/8HHvY91tSWPLWFaMdmj1Cg8ku6G26lec4kWBk nkEuJwcH7QnJg== Received: from fedora-2.home (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 67FAC17E03C6; Wed, 17 Jun 2026 20:50:09 +0200 (CEST) Date: Wed, 17 Jun 2026 20:50:03 +0200 From: Boris Brezillon To: =?UTF-8?B?QWRyacOhbg==?= Larumbe Cc: Steven Price , Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] drm/panthor: Add vm_bind region with kbo range intersection check Message-ID: <20260617205003.07e4275e@fedora-2.home> In-Reply-To: <20260616-vm_bind_checks-v1-1-956198602ae3@collabora.com> References: <20260616-vm_bind_checks-v1-0-956198602ae3@collabora.com> <20260616-vm_bind_checks-v1-1-956198602ae3@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; 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 Tue, 16 Jun 2026 15:46:43 +0100 Adri=C3=A1n Larumbe wrote: > When a VM is created, caller has to specify the range of the address space > carve-out set aside for mapping kernel BO's. That means vm_bind mappings = of > UM-exposed BO's should not intersect with that region, but at the moment > we're not checking this. >=20 > At first, I thought of giving these values to drm_gpuvm_init() through its > reserve_{offset, range} arguments, but it turns out that is meant for VM > address spans that are not managed through the usual drm_gpuvm split/merge > circuit, so I had no choice but to sort of duplicate that functionality in > Panthor. That means we also need to keep that interval recorded in the VM. >=20 > Signed-off-by: Adri=C3=A1n Larumbe > --- > drivers/gpu/drm/panthor/panthor_mmu.c | 33 +++++++++++++++++++++++++++++= ++++ > 1 file changed, 33 insertions(+) >=20 > diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/pant= hor/panthor_mmu.c > index 31cc57029c12..5625f3d34031 100644 > --- a/drivers/gpu/drm/panthor/panthor_mmu.c > +++ b/drivers/gpu/drm/panthor/panthor_mmu.c > @@ -301,6 +301,15 @@ struct panthor_vm { > /** @mm_lock: Lock protecting the @mm field. */ > struct mutex mm_lock; > =20 > + /** @kernel_va: VA-range reserved for kernel BOs. */ > + struct { > + /** @kernel_va.start: Start of the VA-range for kernel BOs. */ > + u64 start; > + > + /** @kernel_va.range: Size of the automatic VA-range for kernel BOs. */ > + u64 range; > + } kernel_va; We can do with a single user_va_end. > + > /** @kernel_auto_va: Automatic VA-range for kernel BOs. */ > struct { > /** @kernel_auto_va.start: Start of the automatic VA-range for kernel = BOs. */ > @@ -1309,6 +1318,24 @@ static int panthor_vm_op_ctx_prealloc_pts(struct p= anthor_vm_op_ctx *op_ctx) > return 0; > } > =20 > +static bool > +panthor_vm_is_kernel_address(struct panthor_vm *vm, > + const struct drm_panthor_vm_bind_op *op) Rather than checking if the VA is not in the kernel range, I'd check that the VA is in the user range, since that's what we want to enforce, and if we ever decide to carve out extra sections above the user-range that the UMD is not supposed to access, we would still catch invalid map/unmap ops. > +{ > + u32 op_type =3D op->flags & DRM_PANTHOR_VM_BIND_OP_TYPE_MASK; > + u64 end, kstart, krange, kend; > + > + if (op_type =3D=3D DRM_PANTHOR_VM_BIND_OP_TYPE_SYNC_ONLY) > + return false; IIRC, we force op->va and op->size to be zero in that case[1], so no need for this extra check IMHO. > + > + end =3D op->va + op->size; > + kstart =3D vm->kernel_va.start; > + krange =3D vm->kernel_va.range; > + kend =3D kstart + krange; > + > + return krange && op->va < kend && kstart < end; A single op->va + op->size <=3D vm->user_va_end; would do, at which point I'm not too sure adding a helper makes sense. > +} > + > #define PANTHOR_VM_BIND_OP_MAP_FLAGS \ > (DRM_PANTHOR_VM_BIND_OP_MAP_READONLY | \ > DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC | \ > @@ -2891,6 +2918,8 @@ panthor_vm_create(struct panthor_device *ptdev, boo= l for_mcu, > } else { > min_va =3D 0; > va_range =3D full_va_range; > + vm->kernel_va.start =3D kernel_va_start; > + vm->kernel_va.range =3D kernel_va_size; > } > =20 > mutex_init(&vm->mm_lock); > @@ -2981,6 +3010,10 @@ panthor_vm_bind_prepare_op_ctx(struct drm_file *fi= le, > if (!IS_ALIGNED(op->va | op->size | op->bo_offset, vm_pgsz)) > return -EINVAL; > =20 > + /* We don't allow mappings that intersect with kbo's reserved range */ > + if (panthor_vm_is_kernel_address(vm, op)) > + return -EINVAL; > + > switch (op->flags & DRM_PANTHOR_VM_BIND_OP_TYPE_MASK) { > case DRM_PANTHOR_VM_BIND_OP_TYPE_MAP: > if (!(op->flags & DRM_PANTHOR_VM_BIND_OP_MAP_SPARSE)) { >=20 [1]https://elixir.bootlin.com/linux/v7.0.11/source/include/uapi/drm/panthor= _drm.h#L588