From: Matthew Brost <matthew.brost@intel.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>,
<intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH] xe/userptr: TLB invalidation new pm_runtime ref before submit
Date: Wed, 15 Jul 2026 12:57:32 -0700 [thread overview]
Message-ID: <alfmLCNnyyXZgOo0@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <b32d3a0f-e0d8-4aed-9a39-f3c317c33c3c@intel.com>
On Wed, Jul 15, 2026 at 04:02:58PM +0100, Matthew Auld wrote:
> On 15/07/2026 15:01, Dnyaneshwar Bhadane wrote:
> > Take a proper runtime PM reference before TLB invalidation.
> > The MMU notifier path has no outer xe_pm_runtime_get()
> > protection, but xe_tlb_inval_fence_init() called from
> > xe_vm_invalidate_vma_submit() uses xe_pm_runtime_get_noresume()
> > which requires an existing reference. The fence itself will
> > hold its own noresume ref until it signals.
>
> Is this fixing a real issue? Do you have a link to a bug report or a splat?
>
> I think fault_mode implies LR, and LR vm is always holding an RPM ref until
> destroyed?
Yes, we should a PM reference if a LR VM is open.
>
> >
> > Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
> > ---
> > drivers/gpu/drm/xe/xe_userptr.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_userptr.c b/drivers/gpu/drm/xe/xe_userptr.c
> > index 1d2ab678faf5..fc7e4b00fe17 100644
> > --- a/drivers/gpu/drm/xe/xe_userptr.c
> > +++ b/drivers/gpu/drm/xe/xe_userptr.c
> > @@ -8,6 +8,7 @@
> > #include <linux/mm.h>
> > +#include "xe_pm.h"
> > #include "xe_tlb_inval.h"
> > #include "xe_trace_bo.h"
> > @@ -103,6 +104,7 @@ xe_vma_userptr_do_inval(struct xe_vm *vm, struct xe_userptr_vma *uvma, bool is_d
> > XE_WARN_ON(err <= 0);
> > if (xe_vm_in_fault_mode(vm) && userptr->initial_bind) {
> > + guard(xe_pm_runtime)(vm->xe);
Also, this is illegal as far as I know. If taking a PM reference wakes
the device, we may allocate memory and acquire a number of locks that
are not permitted in this path, since we are in the reclaim path here.
Lockdep should complain about this, but CI is passing, which suggests
to me that we have an issue somewhere in the lockdep annotations. We
should probably investigate why this is not triggering failures in CI.
If we need a PM reference here, xe_pm_runtime_get_noresume() has the
correct semantics. In the TLB invalidation code paths, we do exactly
this when arming the TLB invalidation fence; see
xe_tlb_inval_fence_init(), if that is failing then we have problem
somewhere else in the code that this code path can be reached without a
PM reference.
Matt
> > if (!userptr->finish_inuse) {
> > /*
> > * Defer the TLB wait to an extra pass so the caller
>
next prev parent reply other threads:[~2026-07-15 19:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 14:01 [PATCH] xe/userptr: TLB invalidation new pm_runtime ref before submit Dnyaneshwar Bhadane
2026-07-15 14:12 ` ✓ CI.KUnit: success for " Patchwork
2026-07-15 15:02 ` [PATCH] " Matthew Auld
2026-07-15 19:57 ` Matthew Brost [this message]
2026-07-15 22:11 ` Matthew Brost
2026-07-15 15:06 ` ✓ Xe.CI.BAT: success for " Patchwork
2026-07-15 16:36 ` ✓ Xe.CI.FULL: " 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=alfmLCNnyyXZgOo0@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=dnyaneshwar.bhadane@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@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