From: Matthew Brost <matthew.brost@intel.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: intel-xe@lists.freedesktop.org,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v2 1/3] drm/xe/userptr: restore invalidation list on error
Date: Mon, 17 Feb 2025 19:58:11 -0800 [thread overview]
Message-ID: <Z7QFUy9ZyBRhPwuY@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <6fec16d5-cbf3-448b-9c07-85a079095f62@intel.com>
On Mon, Feb 17, 2025 at 09:38:26AM +0000, Matthew Auld wrote:
> On 15/02/2025 01:28, Matthew Brost wrote:
> > On Fri, Feb 14, 2025 at 05:05:28PM +0000, Matthew Auld wrote:
> > > On error restore anything still on the pin_list back to the invalidation
> > > list on error. For the actual pin, so long as the vma is tracked on
> > > either list it should get picked up on the next pin, however it looks
> > > possible for the vma to get nuked but still be present on this per vm
> > > pin_list leading to corruption. An alternative might be then to instead
> > > just remove the link when destroying the vma.
> > >
> > > Fixes: ed2bdf3b264d ("drm/xe/vm: Subclass userptr vmas")
> > > Suggested-by: Matthew Brost <matthew.brost@intel.com>
> > > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > Cc: <stable@vger.kernel.org> # v6.8+
> > > ---
> > > drivers/gpu/drm/xe/xe_vm.c | 26 +++++++++++++++++++-------
> > > 1 file changed, 19 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
> > > index d664f2e418b2..668b0bde7822 100644
> > > --- a/drivers/gpu/drm/xe/xe_vm.c
> > > +++ b/drivers/gpu/drm/xe/xe_vm.c
> > > @@ -670,12 +670,12 @@ int xe_vm_userptr_pin(struct xe_vm *vm)
> > > list_for_each_entry_safe(uvma, next, &vm->userptr.invalidated,
> > > userptr.invalidate_link) {
> > > list_del_init(&uvma->userptr.invalidate_link);
> > > - list_move_tail(&uvma->userptr.repin_link,
> > > - &vm->userptr.repin_list);
> > > + list_add_tail(&uvma->userptr.repin_link,
> > > + &vm->userptr.repin_list);
> >
> > Why this change?
>
> Just that with this patch the repin_link should now always be empty at this
> point, I think. add should complain if that is not the case.
>
If it is always expected to be empty, then yea maybe add a xe_assert for
this as the list management is pretty tricky.
> >
> > > }
> > > spin_unlock(&vm->userptr.invalidated_lock);
> > > - /* Pin and move to temporary list */
> > > + /* Pin and move to bind list */
> > > list_for_each_entry_safe(uvma, next, &vm->userptr.repin_list,
> > > userptr.repin_link) {
> > > err = xe_vma_userptr_pin_pages(uvma);
> > > @@ -691,10 +691,10 @@ int xe_vm_userptr_pin(struct xe_vm *vm)
> > > err = xe_vm_invalidate_vma(&uvma->vma);
> > > xe_vm_unlock(vm);
> > > if (err)
> > > - return err;
> > > + break;
> > > } else {
> > > - if (err < 0)
> > > - return err;
> > > + if (err)
> > > + break;
> > > list_del_init(&uvma->userptr.repin_link);
> > > list_move_tail(&uvma->vma.combined_links.rebind,
> > > @@ -702,7 +702,19 @@ int xe_vm_userptr_pin(struct xe_vm *vm)
> > > }
> > > }
> > > - return 0;
> > > + if (err) {
> > > + down_write(&vm->userptr.notifier_lock);
> >
> > Can you explain why you take the notifier lock here? I don't think this
> > required unless I'm missing something.
>
> For the invalidated list, the docs say:
>
> "Removing items from the list additionally requires @lock in write mode, and
> adding items to the list requires the @userptr.notifer_lock in write mode."
>
> Not sure if the docs needs to be updated here?
>
Oh. I believe the part of comment for 'adding items to the list
requires the @userptr.notifer_lock in write mode' really means something
like this:
'When adding to @vm->userptr.invalidated in the notifier the
@userptr.notifer_lock in write mode protects against concurrent VM binds
from setting up newly invalidated pages.'
So with above and since this code path is in the VM bind path (i.e. we
are not racing with other binds) I think the
vm->userptr.invalidated_lock is sufficient. Maybe ask Thomas if he
agrees here.
Matt
> >
> > Matt
> >
> > > + spin_lock(&vm->userptr.invalidated_lock);
> > > + list_for_each_entry_safe(uvma, next, &vm->userptr.repin_list,
> > > + userptr.repin_link) {
> > > + list_del_init(&uvma->userptr.repin_link);
> > > + list_move_tail(&uvma->userptr.invalidate_link,
> > > + &vm->userptr.invalidated);
> > > + }
> > > + spin_unlock(&vm->userptr.invalidated_lock);
> > > + up_write(&vm->userptr.notifier_lock);
> > > + }
> > > + return err;
> > > }
> > > /**
> > > --
> > > 2.48.1
> > >
>
next prev parent reply other threads:[~2025-02-18 3:57 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-14 17:05 [PATCH v2 1/3] drm/xe/userptr: restore invalidation list on error Matthew Auld
2025-02-14 17:05 ` [PATCH v2 2/3] drm/xe/userptr: fix EFAULT handling Matthew Auld
2025-02-15 1:23 ` Matthew Brost
2025-02-17 9:19 ` Matthew Auld
2025-02-14 17:05 ` [PATCH v2 3/3] drm/xe/userptr: remove tmp_evict list Matthew Auld
2025-02-14 17:35 ` ✓ CI.Patch_applied: success for series starting with [v2,1/3] drm/xe/userptr: restore invalidation list on error Patchwork
2025-02-14 17:35 ` ✓ CI.checkpatch: " Patchwork
2025-02-14 17:36 ` ✓ CI.KUnit: " Patchwork
2025-02-14 17:53 ` ✓ CI.Build: " Patchwork
2025-02-14 17:55 ` ✓ CI.Hooks: " Patchwork
2025-02-14 17:56 ` ✓ CI.checksparse: " Patchwork
2025-02-15 1:28 ` [PATCH v2 1/3] " Matthew Brost
2025-02-17 9:38 ` Matthew Auld
2025-02-18 3:58 ` Matthew Brost [this message]
2025-02-20 23:52 ` Matthew Brost
2025-02-21 11:11 ` Matthew Auld
2025-02-21 11:20 ` Thomas Hellström
2025-02-21 13:17 ` Matthew Auld
2025-02-21 13:23 ` Thomas Hellström
2025-02-17 7:46 ` ✓ CI.Patch_applied: success for series starting with [v2,1/3] drm/xe/userptr: restore invalidation list on error (rev2) Patchwork
2025-02-17 7:47 ` ✓ CI.checkpatch: " Patchwork
2025-02-17 7:48 ` ✓ CI.KUnit: " Patchwork
2025-02-17 7:51 ` ✗ Xe.CI.Full: failure for series starting with [v2,1/3] drm/xe/userptr: restore invalidation list on error Patchwork
2025-02-17 8:04 ` ✓ CI.Build: success for series starting with [v2,1/3] drm/xe/userptr: restore invalidation list on error (rev2) Patchwork
2025-02-17 8:07 ` ✓ CI.Hooks: " Patchwork
2025-02-17 8:08 ` ✓ CI.checksparse: " Patchwork
2025-02-17 8:27 ` ✓ Xe.CI.BAT: " Patchwork
2025-02-17 10:47 ` ✗ Xe.CI.Full: failure " Patchwork
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=Z7QFUy9ZyBRhPwuY@lstrano-desk.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=stable@vger.kernel.org \
--cc=thomas.hellstrom@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox