mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Box <david.e.box@linux.intel.com>
To: ilpo.jarvinen@linux.intel.com, linux-kernel@vger.kernel.org,
	 platform-driver-x86@vger.kernel.org, rodrigo.vivi@intel.com,
	michael.j.ruhl@intel.com,  ayaz.siddiqui@intel.com,
	syed.abdul.muqthyar.ahmed@intel.com,
	 intel-xe@lists.freedesktop.org, hansg@kernel.org
Subject: Re: [PATCH v3 1/1] platform/x86/intel/pmt: Notify userspace when crashlogs complete
Date: Fri, 13 Nov 2026 13:20:55 -0800	[thread overview]
Message-ID: <179460474975.2604806.7772916319418845665@linux.intel.com> (raw)
In-Reply-To: <c265bd093c23d96417cb5c6504938c90adc36ac9.1794444671.git.david.e.box@linux.intel.com>

Sashiko's report [1] is right, and the underlying problem isn't one the
crashlog driver can fix on its own. Please hold off on this version.

The problem

On BMG and CRI, PMT features share one MMIO window, and a SoC remapper
index selects which region it shows. That is why PMT has callbacks: the
parent switches the window and performs the access under its lock
(xe->pmt.lock). On CRI the read_reg()/write_reg() callbacks cover the
discovery status and control areas.

For CRI, xe also holds pmt.lock across intel_vsec_register() with the
window parked on discovery, because the PMT drivers read their
discovery headers directly rather than through a callback. But a PMT
driver's probe also needs its own regions: crashlog reads its status
through read_reg(), which must take pmt.lock to switch the window. v2
deadlocked on exactly that, and v3 hit the same lock through an ABBA
with control_mutex (what Sashiko found). Remove has the same problem,
and the lock doesn't protect a PMT driver loaded after registration.

What it takes to fix

1. Document the contract in include/linux/intel_vsec.h: callbacks may
   be called from the client's probe and remove, so a parent must not
   hold a lock its callbacks take across intel_vsec_register() or
   device removal. I'll send that patch.

2. Have xe switch the window only at the time of each access, as
   xe_pmt_telem_read() already does, and stop holding pmt.lock across
   registration. The only thing that requires holding it today is the
   PMT drivers' direct discovery-header reads. Since the headers are
   static, xe can copy the discovery tables under the lock before
   registering and pass the copy in, and the PMT drivers can decode
   from it. Live status and control stay on read_reg()/write_reg().
   I'll can do the PMT side.

3. Then v4 of this patch returns to the simpler v2 design: check for a
   completed crashlog directly in probe, with no work item. The other
   v3 fixes stay.

Michael, does switching the window only at access time work for CRI,
and are there other direct reads of the window I'm missing? Ilpo, are
you OK with the documented contract and with the PMT drivers decoding
discovery headers from a copy the parent provides?

[1] https://lore.kernel.org/all/sashiko-outbox-210176@kernel.org/

David

      reply	other threads:[~2026-11-13 21:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12  2:08 [PATCH v3 0/1] " David E. Box
2026-11-12  2:08 ` [PATCH v3 1/1] " David E. Box
2026-11-13 21:20   ` David Box [this message]

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=179460474975.2604806.7772916319418845665@linux.intel.com \
    --to=david.e.box@linux.intel.com \
    --cc=ayaz.siddiqui@intel.com \
    --cc=hansg@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.j.ruhl@intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=syed.abdul.muqthyar.ahmed@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

all inboxes | Powered by JetHome®