From: Matthew Brost <matthew.brost@intel.com>
To: <maarten.lankhorst@linux.intel.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>, intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH 3/4] drm/xe: Add vm snapshot mutex for easily taking a vm snapshot during devcoredump
Date: Fri, 13 Oct 2023 19:21:46 +0000 [thread overview]
Message-ID: <ZSmYyklINGOJ4RO2@DUT025-TGLU.fm.intel.com> (raw)
In-Reply-To: <20231013152142.52869-4-maarten.lankhorst@linux.intel.com>
On Fri, Oct 13, 2023 at 05:21:41PM +0200, maarten.lankhorst@linux.intel.com wrote:
> From: Maarten Lankhorst <dev@lankhorst.se>
>
> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
> ---
> drivers/gpu/drm/xe/xe_vm.c | 7 +++++++
> drivers/gpu/drm/xe/xe_vm_types.h | 5 +++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
> index da006249147e..544d998293d3 100644
> --- a/drivers/gpu/drm/xe/xe_vm.c
> +++ b/drivers/gpu/drm/xe/xe_vm.c
> @@ -1163,7 +1163,9 @@ static int xe_vm_insert_vma(struct xe_vm *vm, struct xe_vma *vma)
> xe_assert(vm->xe, xe_vma_vm(vma) == vm);
> lockdep_assert_held(&vm->lock);
>
> + mutex_lock(&vm->snap_mutex);
I can't say I'm a fan of adding a new lock. Can you explain why this is
needed? e.g. Why does the exisiting &vm->lock not work? We have lockdep
annotations in both xe_vm_insert_vma & xe_vm_remove_vma that vm->lock is
held. As is, the capture should be able to take vm->lock in write mode
and this is safe.
Side note the annotations should probably be in write mode for
xe_vm_insert_vma & xe_vm_remove_vma and the capture should be able to
take this in read mode. We should double check on this.
Matt
> err = drm_gpuva_insert(&vm->gpuvm, &vma->gpuva);
> + mutex_unlock(&vm->snap_mutex);
> XE_WARN_ON(err); /* Shouldn't be possible */
>
> return err;
> @@ -1174,7 +1176,9 @@ static void xe_vm_remove_vma(struct xe_vm *vm, struct xe_vma *vma)
> xe_assert(vm->xe, xe_vma_vm(vma) == vm);
> lockdep_assert_held(&vm->lock);
>
> + mutex_lock(&vm->snap_mutex);
> drm_gpuva_remove(&vma->gpuva);
> + mutex_unlock(&vm->snap_mutex);
> if (vm->usm.last_fault_vma == vma)
> vm->usm.last_fault_vma = NULL;
> }
> @@ -1343,6 +1347,7 @@ struct xe_vm *xe_vm_create(struct xe_device *xe, u32 flags)
> vm->flags = flags;
>
> init_rwsem(&vm->lock);
> + mutex_init(&vm->snap_mutex);
>
> INIT_LIST_HEAD(&vm->rebind_list);
>
> @@ -1486,6 +1491,7 @@ struct xe_vm *xe_vm_create(struct xe_device *xe, u32 flags)
> dma_resv_unlock(&vm->resv);
> drm_gpuvm_destroy(&vm->gpuvm);
> err_put:
> + mutex_destroy(&vm->snap_mutex);
> dma_resv_fini(&vm->resv);
> for_each_tile(tile, xe, id)
> xe_range_fence_tree_fini(&vm->rftree[id]);
> @@ -1625,6 +1631,7 @@ void xe_vm_close_and_put(struct xe_vm *vm)
> up_write(&vm->lock);
>
> drm_gpuvm_destroy(&vm->gpuvm);
> + mutex_destroy(&vm->snap_mutex);
>
> mutex_lock(&xe->usm.lock);
> if (vm->flags & XE_VM_FLAG_FAULT_MODE)
> diff --git a/drivers/gpu/drm/xe/xe_vm_types.h b/drivers/gpu/drm/xe/xe_vm_types.h
> index 825f8127741e..bf5017b631a5 100644
> --- a/drivers/gpu/drm/xe/xe_vm_types.h
> +++ b/drivers/gpu/drm/xe/xe_vm_types.h
> @@ -183,6 +183,11 @@ struct xe_vm {
> * VM
> */
> struct rw_semaphore lock;
> + /**
> + * @snap_mutex: Mutex used to guard insertions and removals from gpuva,
> + * so we can take a snapshot safely from devcoredump.
> + */
> + struct mutex snap_mutex;
>
> /**
> * @rebind_list: list of VMAs that need rebinding, and if they are
> --
> 2.40.1
>
next prev parent reply other threads:[~2023-10-13 19:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-13 15:21 [Intel-xe] [PATCH 0/4] RFC for discussion of devcoredump uapi maarten.lankhorst
2023-10-13 15:21 ` [Intel-xe] [PATCH 1/4] drm/xe: Add uapi for dumpable bos maarten.lankhorst
2023-10-13 15:21 ` [Intel-xe] [PATCH 2/4] drm/xe: Annotate each dumpable vma as such maarten.lankhorst
2023-10-13 15:21 ` [Intel-xe] [PATCH 3/4] drm/xe: Add vm snapshot mutex for easily taking a vm snapshot during devcoredump maarten.lankhorst
2023-10-13 19:21 ` Matthew Brost [this message]
2023-10-17 10:15 ` Maarten Lankhorst
2023-10-13 15:21 ` [Intel-xe] [PATCH 4/4] drm/xe: Almost implement snapshot support maarten.lankhorst
2023-10-13 17:23 ` [Intel-xe] ✓ CI.Patch_applied: success for RFC for discussion of devcoredump uapi Patchwork
2023-10-13 17:23 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-10-13 17:24 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-10-13 17:31 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-10-13 17:32 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-10-13 17:33 ` [Intel-xe] ✓ CI.checksparse: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2023-10-24 12:22 [Intel-xe] [PATCH 0/4] drm/xe: Implement snapshot support Maarten, Lankhorst <maarten.lankhorst
2023-10-24 12:22 ` [Intel-xe] [PATCH 3/4] drm/xe: Add vm snapshot mutex for easily taking a vm snapshot during devcoredump Maarten, Lankhorst <maarten.lankhorst
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=ZSmYyklINGOJ4RO2@DUT025-TGLU.fm.intel.com \
--to=matthew.brost@intel.com \
--cc=dev@lankhorst.se \
--cc=intel-xe@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
/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.