All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liviu Dudau <liviu.dudau@arm.com>
To: Ketil Johnsen <ketil.johnsen@arm.com>
Cc: Boris Brezillon <boris.brezillon@collabora.com>,
	Steven Price <steven.price@arm.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Daniel Almeida <daniel.almeida@collabora.com>,
	Alice Ryhl <aliceryhl@google.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/7] drm/panthor: Explicit expansion of locked VM region
Date: Thu, 30 Jul 2026 11:47:34 +0100	[thread overview]
Message-ID: <amsrxqUXNYhFDPz-@e142607> (raw)
In-Reply-To: <20260712135439.1546950-4-ketil.johnsen@arm.com>

On Sun, Jul 12, 2026 at 03:54:35PM +0200, Ketil Johnsen wrote:
> Currently the panthor_vm_lock_region() function will implicitly expand
> an already locked VM region. This can be problematic because the caller
> do not reliably know if it needs to call panthor_vm_unlock_region()
> or not.
> 
> Worth noting, there is currently no known issues with this as the code
> is written today.
> 
> This change introduces panthor_vm_expand_region() which will only work
> if there is already a locked VM region. This again means that the
> original lock and unlock functions can work as a pair. This pairing is
> needed for subsequent protected memory changes.
> 
> Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>

Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>

Best regards,
Liviu

> ---
>  drivers/gpu/drm/panthor/panthor_mmu.c | 87 +++++++++++++++++++--------
>  1 file changed, 62 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
> index 1f6b9242279c2..b82b01013611c 100644
> --- a/drivers/gpu/drm/panthor/panthor_mmu.c
> +++ b/drivers/gpu/drm/panthor/panthor_mmu.c
> @@ -1774,20 +1774,49 @@ static const char *access_type_name(struct panthor_device *ptdev,
>  	}
>  }
>  
> +static int panthor_vm_apply_as_lock(struct panthor_vm *vm, u64 region)
> +{
> +	struct panthor_device *ptdev = vm->ptdev;
> +
> +	lockdep_assert_held(&ptdev->mmu->as.slots_lock);
> +
> +	gpu_write64(ptdev->mmu->iomem, AS_LOCKADDR(vm->as.id), region);
> +	return as_send_cmd_and_wait(ptdev, vm->as.id, AS_COMMAND_LOCK);
> +}
> +
>  static int panthor_vm_lock_region(struct panthor_vm *vm, u64 start, u64 size)
>  {
>  	struct panthor_device *ptdev = vm->ptdev;
>  	int ret = 0;
>  
> -	/* sm_step_remap() can call panthor_vm_lock_region() to account for
> -	 * the wider unmap needed when doing a partial huge page unamp. We
> -	 * need to ignore the lock if it's already part of the locked region.
> -	 */
> -	if (start >= vm->locked_region.start &&
> -	    start + size <= vm->locked_region.start + vm->locked_region.size)
> -		return 0;
> +	if (drm_WARN_ON(&ptdev->base, vm->locked_region.size))
> +		return -EINVAL;
> +
> +	mutex_lock(&ptdev->mmu->as.slots_lock);
> +	if (vm->as.id >= 0 && size) {
> +		u64 region = pack_region_range(ptdev, &start, &size);
> +
> +		ret = panthor_vm_apply_as_lock(vm, region);
> +	}
>  
> -	/* sm_step_remap() may need a locked region that isn't a strict superset
> +	if (!ret) {
> +		vm->locked_region.start = start;
> +		vm->locked_region.size = size;
> +	}
> +	mutex_unlock(&ptdev->mmu->as.slots_lock);
> +
> +	return ret;
> +}
> +
> +static int panthor_vm_expand_locked_region(struct panthor_vm *vm,
> +					   u64 start, u64 size)
> +{
> +	struct panthor_device *ptdev = vm->ptdev;
> +	u64 end;
> +	int ret = 0;
> +
> +	/* This function is here to handle the following case:
> +	 * 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 beyond
>  	 * it to deal with partial unmaps of transparent huge pages. What we want
>  	 * in those cases is to lock the union of both regions. The new region must
> @@ -1795,25 +1824,30 @@ static int panthor_vm_lock_region(struct panthor_vm *vm, u64 start, u64 size)
>  	 * boundaries in a remap operation can only shift up or down respectively,
>  	 * but never otherwise.
>  	 */
> -	if (vm->locked_region.size) {
> -		u64 end = max(vm->locked_region.start + vm->locked_region.size,
> -			      start + size);
>  
> -		drm_WARN_ON_ONCE(&vm->ptdev->base, (start + size <= vm->locked_region.start) ||
> -				 (start >= vm->locked_region.start + vm->locked_region.size));
> +	/* This function can only expand an already locked region */
> +	if (drm_WARN_ON(&ptdev->base, !vm->locked_region.size))
> +		return -EINVAL;
> +
> +	/* Early out if requested range is already locked */
> +	if (start >= vm->locked_region.start &&
> +	    start + size <= vm->locked_region.start + vm->locked_region.size)
> +		return 0;
>  
> -		start = min(start, vm->locked_region.start);
> -		size = end - start;
> -	}
> +	end = max(vm->locked_region.start + vm->locked_region.size,
> +		  start + size);
> +
> +	drm_WARN_ON_ONCE(&ptdev->base, (start + size <= vm->locked_region.start) ||
> +			 (start >= vm->locked_region.start + vm->locked_region.size));
> +
> +	start = min(start, vm->locked_region.start);
> +	size = end - start;
>  
>  	mutex_lock(&ptdev->mmu->as.slots_lock);
>  	if (vm->as.id >= 0 && size) {
> -		/* Lock the region that needs to be updated */
> -		gpu_write64(ptdev->mmu->iomem, AS_LOCKADDR(vm->as.id),
> -			    pack_region_range(ptdev, &start, &size));
> +		u64 region = pack_region_range(ptdev, &start, &size);
>  
> -		/* If the lock succeeded, update the locked_region info. */
> -		ret = as_send_cmd_and_wait(ptdev, vm->as.id, AS_COMMAND_LOCK);
> +		ret = panthor_vm_apply_as_lock(vm, region);
>  	}
>  
>  	if (!ret) {
> @@ -2367,11 +2401,14 @@ static int panthor_gpuva_sm_step_remap(struct drm_gpuva_op *op,
>  		 */
>  		unmap_hugepage_align(&op->remap, &unmap_start, &unmap_range);
>  
> -		/* If the range changed, we might have to lock a wider region to guarantee
> -		 * atomicity. panthor_vm_lock_region() bails out early if the new region
> -		 * is already part of the locked region, so no need to do this check here.
> +		/* If the range changed, we might have to lock a wider region to
> +		 * guarantee atomicity.
>  		 */
> -		panthor_vm_lock_region(vm, unmap_start, unmap_range);
> +		ret = panthor_vm_expand_locked_region(vm, unmap_start,
> +						      unmap_range);
> +		if (ret)
> +			return ret;
> +
>  		panthor_vm_unmap_pages(vm, unmap_start, unmap_range);
>  	}
>  
> -- 
> 2.43.0
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

  parent reply	other threads:[~2026-07-30 10:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-12 13:54 [PATCH v2 0/7] drm/panthor: Protected mode support for Mali CSF GPUs Ketil Johnsen
2026-07-12 13:54 ` [PATCH v2 1/7] drm/panthor: De-duplicate FW memory section sync Ketil Johnsen
2026-07-22 15:59   ` Steven Price
2026-07-12 13:54 ` [PATCH v2 2/7] drm/panthor: Minor scheduler refactoring Ketil Johnsen
2026-07-24 14:57   ` Steven Price
2026-07-30  9:48   ` Liviu Dudau
2026-07-12 13:54 ` [PATCH v2 3/7] drm/panthor: Explicit expansion of locked VM region Ketil Johnsen
2026-07-13  6:56   ` Boris Brezillon
2026-07-30 10:47   ` Liviu Dudau [this message]
2026-07-12 13:54 ` [PATCH v2 4/7] drm/panthor: Pass drm_file instead of panthor_file Ketil Johnsen
2026-07-24 15:02   ` Steven Price
2026-07-12 13:54 ` [PATCH v2 5/7] drm/panthor: Don't allocate protm_suspend_buf Ketil Johnsen
2026-07-13  7:02   ` Boris Brezillon
2026-07-24 15:03   ` Steven Price
2026-07-30 10:50   ` Liviu Dudau
2026-07-12 13:54 ` [PATCH v2 6/7] drm/panthor: Add support for entering and exiting protected mode Ketil Johnsen
2026-07-13  8:37   ` Boris Brezillon
2026-07-12 13:54 ` [PATCH v2 7/7] drm/panthor: Expose protected rendering features Ketil Johnsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amsrxqUXNYhFDPz-@e142607 \
    --to=liviu.dudau@arm.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=boris.brezillon@collabora.com \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ketil.johnsen@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=steven.price@arm.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.