On 2026-06-30 10:23:36+02:00, Boris Brezillon wrote: > On Mon, 29 Jun 2026 21:17:08 +0100 > Adrián Larumbe <[email protected]> wrote: > > > This check is being already carried out further down the call stack inside > > drm_gpuvm_sm_map -> drm_gpuvm_range_valid, but it's best to fail early in > > the driver before GPUVM functions are invoked so that we won't waste time > > allocating vm_bind context resources. > > > > Reported-by: Sashiko <[email protected]> > > Closes: > > https://sashiko.dev/#/message/20260623204220.CDB1B1F000E9%40smtp.kernel.org > > Fixes: 12cf826bf1dd ("drm/panthor: Support sparse mappings") > > Signed-off-by: Adrián Larumbe <[email protected]> > > --- > > drivers/gpu/drm/panthor/panthor_mmu.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c > > b/drivers/gpu/drm/panthor/panthor_mmu.c > > index 77fdad4e5166..8bd9b975e5ce 100644 > > --- a/drivers/gpu/drm/panthor/panthor_mmu.c > > +++ b/drivers/gpu/drm/panthor/panthor_mmu.c > > @@ -1328,6 +1328,7 @@ static int panthor_vm_prepare_map_op_ctx(struct > > panthor_vm_op_ctx *op_ctx, > > struct drm_gpuvm_bo *preallocated_vm_bo; > > struct sg_table *sgt = NULL; > > int ret; > > + u64 end; > > > > if (!bo) > > return -EINVAL; > > @@ -1353,6 +1354,10 @@ static int panthor_vm_prepare_map_op_ctx(struct > > panthor_vm_op_ctx *op_ctx, > > if (is_sparse && (op->bo_handle || op->bo_offset)) > > return -EINVAL; > > > > + /* Protect against sparse VA range overflow */ > > + if (is_sparse && check_add_overflow(op->va, op->size, &end)) > > + return -EINVAL; > > Why should we limit this to sparse? Feels like the overflow check is > good to have for non-sparse as well.
You're right, it should be done for all unmaps. On top of that, Sashiko pointed this out: New issues: - [Low] The newly added overflow check in `panthor_vm_prepare_unmap_op_ctx` is mathematically dead code because the `MAP_SPARSE` flag is explicitly rejected for UNMAP operations. - [Low] The overflow check in `panthor_vm_prepare_map_op_ctx` is artificially restricted to sparse mappings, bypassing early protection for non-sparse mappings. So it turns out that by limiting the overflow check to sparse unmaps, I've introduced a NOP. That also made me think that even though in the uAPI we state the following: * @DRM_PANTHOR_VM_BIND_OP_MAP_SPARSE: Sparsely map a virtual memory range * * Only valid with DRM_PANTHOR_VM_BIND_OP_TYPE_MAP. I wrote no checks to validate this for the sparse mappings patch series. So for v4 I'll be doing the overflow check unconditionally in panthor_vm_prepare_unmap_op_ctx() and also return -EINVAL if DRM_PANTHOR_VM_BIND_OP_MAP_SPARSE is among the op flags. Second Sashiko issue isn't relevant because right at the next statement we're clamping limiting mapping ranges to the size of BOs. Cheers, Adrian
