All of lore.kernel.org
 help / color / mirror / Atom feed
* [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
@ 2022-06-30 21:00 Stuart Summers
  2022-06-30 21:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix NPD in PMU during driver teardown (rev2) Patchwork
                   ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: Stuart Summers @ 2022-06-30 21:00 UTC (permalink / raw)
  Cc: intel-gfx

In the driver teardown, we are unregistering the gt prior
to unregistering the PMU. This means there is a small window
of time in which the application can request metrics from the
PMU, some of which are calling into the uapi engines list,
while the engines are not available. In this case we can
see null pointer dereferences.

Fix this ordering in both the driver load and unload sequences.

Additionally add a check for engine presence to prevent this
NPD in the event this ordering is accidentally reversed. Print
a debug message indicating when they aren't available.

v1: Actually address the driver load/unload ordering issue

Signed-off-by: Stuart Summers <stuart.summers@intel.com>
---
 drivers/gpu/drm/i915/i915_driver.c | 11 ++---
 drivers/gpu/drm/i915/i915_pmu.c    | 72 +++++++++++++++++-------------
 2 files changed, 48 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
index deb8a8b76965..ee4dcb85d206 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -717,7 +717,6 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
 	struct drm_device *dev = &dev_priv->drm;
 
 	i915_gem_driver_register(dev_priv);
-	i915_pmu_register(dev_priv);
 
 	intel_vgpu_register(dev_priv);
 
@@ -731,11 +730,12 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
 	i915_debugfs_register(dev_priv);
 	i915_setup_sysfs(dev_priv);
 
+	intel_gt_driver_register(to_gt(dev_priv));
+
 	/* Depends on sysfs having been initialized */
+	i915_pmu_register(dev_priv);
 	i915_perf_register(dev_priv);
 
-	intel_gt_driver_register(to_gt(dev_priv));
-
 	intel_display_driver_register(dev_priv);
 
 	intel_power_domains_enable(dev_priv);
@@ -762,11 +762,12 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv)
 
 	intel_display_driver_unregister(dev_priv);
 
-	intel_gt_driver_unregister(to_gt(dev_priv));
-
 	i915_perf_unregister(dev_priv);
+	/* GT should be available until PMU is gone */
 	i915_pmu_unregister(dev_priv);
 
+	intel_gt_driver_unregister(to_gt(dev_priv));
+
 	i915_teardown_sysfs(dev_priv);
 	drm_dev_unplug(&dev_priv->drm);
 
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 958b37123bf1..796a1d8e36f2 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -670,21 +670,28 @@ static void i915_pmu_enable(struct perf_event *event)
 	if (is_engine_event(event)) {
 		u8 sample = engine_event_sample(event);
 		struct intel_engine_cs *engine;
-
-		engine = intel_engine_lookup_user(i915,
-						  engine_event_class(event),
-						  engine_event_instance(event));
-
-		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
-			     I915_ENGINE_SAMPLE_COUNT);
-		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
-			     I915_ENGINE_SAMPLE_COUNT);
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
-		GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
-
-		engine->pmu.enable |= BIT(sample);
-		engine->pmu.enable_count[sample]++;
+		u8 class = engine_event_class(event);
+		u8 instance = engine_event_instance(event);
+
+		engine = intel_engine_lookup_user(i915, class, instance);
+		if (engine) {
+			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
+				     I915_ENGINE_SAMPLE_COUNT);
+			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
+				     I915_ENGINE_SAMPLE_COUNT);
+			GEM_BUG_ON(sample >=
+				   ARRAY_SIZE(engine->pmu.enable_count));
+			GEM_BUG_ON(sample >=
+				   ARRAY_SIZE(engine->pmu.sample));
+			GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
+
+			engine->pmu.enable |= BIT(sample);
+			engine->pmu.enable_count[sample]++;
+		} else {
+			drm_dbg(&i915->drm,
+				"Invalid engine event: { class:%d, inst:%d }\n",
+				class, instance);
+		}
 	}
 
 	spin_unlock_irqrestore(&pmu->lock, flags);
@@ -714,21 +721,26 @@ static void i915_pmu_disable(struct perf_event *event)
 	if (is_engine_event(event)) {
 		u8 sample = engine_event_sample(event);
 		struct intel_engine_cs *engine;
-
-		engine = intel_engine_lookup_user(i915,
-						  engine_event_class(event),
-						  engine_event_instance(event));
-
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
-		GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
-
-		/*
-		 * Decrement the reference count and clear the enabled
-		 * bitmask when the last listener on an event goes away.
-		 */
-		if (--engine->pmu.enable_count[sample] == 0)
-			engine->pmu.enable &= ~BIT(sample);
+		u8 class = engine_event_class(event);
+		u8 instance = engine_event_instance(event);
+
+		engine = intel_engine_lookup_user(i915, class, instance);
+		if (engine) {
+			GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
+			GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
+			GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
+
+			/*
+			 * Decrement the reference count and clear the enabled
+			 * bitmask when the last listener on an event goes away.
+			 */
+			if (--engine->pmu.enable_count[sample] == 0)
+				engine->pmu.enable &= ~BIT(sample);
+		} else {
+			drm_dbg(&i915->drm,
+				"Invalid engine event: { class:%d, inst:%d }\n",
+				class, instance);
+		}
 	}
 
 	GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix NPD in PMU during driver teardown (rev2)
  2022-06-30 21:00 [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown Stuart Summers
@ 2022-06-30 21:39 ` Patchwork
  2022-07-01  0:11 ` [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown Umesh Nerlige Ramappa
  2022-07-01 13:54 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix NPD in PMU during driver teardown (rev2) Patchwork
  2 siblings, 0 replies; 21+ messages in thread
From: Patchwork @ 2022-06-30 21:39 UTC (permalink / raw)
  To: Stuart Summers; +Cc: intel-gfx

[-- Attachment #1: Type: text/plain, Size: 8147 bytes --]

== Series Details ==

Series: drm/i915: Fix NPD in PMU during driver teardown (rev2)
URL   : https://patchwork.freedesktop.org/series/105790/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11835 -> Patchwork_105790v2
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/index.html

Participating hosts (39 -> 40)
------------------------------

  Additional (2): bat-dg2-8 fi-bxt-dsi 
  Missing    (1): fi-tgl-u2 

Known issues
------------

  Here are the changes found in Patchwork_105790v2 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_huc_copy@huc-copy:
    - fi-bxt-dsi:         NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/fi-bxt-dsi/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@verify-random:
    - fi-bxt-dsi:         NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 similar issues
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/fi-bxt-dsi/igt@gem_lmem_swapping@verify-random.html

  * igt@gem_tiled_blits@basic:
    - fi-bxt-dsi:         NOTRUN -> [SKIP][3] ([fdo#109271]) +12 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/fi-bxt-dsi/igt@gem_tiled_blits@basic.html

  * igt@i915_selftest@live@gem:
    - fi-pnv-d510:        NOTRUN -> [DMESG-FAIL][4] ([i915#4528])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/fi-pnv-d510/igt@i915_selftest@live@gem.html

  * igt@i915_selftest@live@hangcheck:
    - bat-dg1-6:          [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] / [i915#4957])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/bat-dg1-6/igt@i915_selftest@live@hangcheck.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/bat-dg1-6/igt@i915_selftest@live@hangcheck.html

  * igt@i915_selftest@live@late_gt_pm:
    - fi-bsw-nick:        [PASS][7] -> [DMESG-FAIL][8] ([i915#3428])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@i915_selftest@live@requests:
    - fi-blb-e6850:       [PASS][9] -> [DMESG-FAIL][10] ([i915#4528])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/fi-blb-e6850/igt@i915_selftest@live@requests.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/fi-blb-e6850/igt@i915_selftest@live@requests.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-rkl-11600:       NOTRUN -> [SKIP][11] ([fdo#111827])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/fi-rkl-11600/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-edid-read:
    - fi-bxt-dsi:         NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/fi-bxt-dsi/igt@kms_chamelium@hdmi-edid-read.html

  * igt@runner@aborted:
    - fi-bsw-nick:        NOTRUN -> [FAIL][13] ([fdo#109271] / [i915#3428] / [i915#4312])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/fi-bsw-nick/igt@runner@aborted.html

  
#### Possible fixes ####

  * igt@core_hotunplug@unbind-rebind:
    - {bat-adln-1}:       [DMESG-WARN][14] ([i915#6297]) -> [PASS][15]
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/bat-adln-1/igt@core_hotunplug@unbind-rebind.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/bat-adln-1/igt@core_hotunplug@unbind-rebind.html

  * igt@i915_selftest@live@requests:
    - fi-pnv-d510:        [DMESG-FAIL][16] ([i915#4528]) -> [PASS][17]
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/fi-pnv-d510/igt@i915_selftest@live@requests.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/fi-pnv-d510/igt@i915_selftest@live@requests.html

  * igt@i915_suspend@basic-s3-without-i915:
    - fi-rkl-11600:       [INCOMPLETE][18] ([i915#5982]) -> [PASS][19]
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html

  * igt@kms_busy@basic@modeset:
    - {bat-adln-1}:       [DMESG-WARN][20] ([i915#3576]) -> [PASS][21] +1 similar issue
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/bat-adln-1/igt@kms_busy@basic@modeset.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/bat-adln-1/igt@kms_busy@basic@modeset.html

  * igt@kms_flip@basic-plain-flip@a-edp1:
    - {bat-adlp-6}:       [DMESG-WARN][22] ([i915#3576]) -> [PASS][23] +1 similar issue
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/bat-adlp-6/igt@kms_flip@basic-plain-flip@a-edp1.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/bat-adlp-6/igt@kms_flip@basic-plain-flip@a-edp1.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
  [i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
  [i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
  [i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
  [i915#5174]: https://gitlab.freedesktop.org/drm/intel/issues/5174
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#5763]: https://gitlab.freedesktop.org/drm/intel/issues/5763
  [i915#5903]: https://gitlab.freedesktop.org/drm/intel/issues/5903
  [i915#5982]: https://gitlab.freedesktop.org/drm/intel/issues/5982
  [i915#6297]: https://gitlab.freedesktop.org/drm/intel/issues/6297


Build changes
-------------

  * Linux: CI_DRM_11835 -> Patchwork_105790v2

  CI-20190529: 20190529
  CI_DRM_11835: 04a306d4367231c6a86c1d415eb2596aaf7aca5f @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6553: 3cf110f8dcd1f4f02cf84339664b413abdaebf7d @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_105790v2: 04a306d4367231c6a86c1d415eb2596aaf7aca5f @ git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

6d4ed6d1bdae drm/i915: Fix NPD in PMU during driver teardown

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/index.html

[-- Attachment #2: Type: text/html, Size: 8303 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-06-30 21:00 [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown Stuart Summers
  2022-06-30 21:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix NPD in PMU during driver teardown (rev2) Patchwork
@ 2022-07-01  0:11 ` Umesh Nerlige Ramappa
  2022-07-01  8:37   ` Tvrtko Ursulin
  2022-07-01 13:54 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix NPD in PMU during driver teardown (rev2) Patchwork
  2 siblings, 1 reply; 21+ messages in thread
From: Umesh Nerlige Ramappa @ 2022-07-01  0:11 UTC (permalink / raw)
  To: Stuart Summers; +Cc: intel-gfx

On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart Summers wrote:
>In the driver teardown, we are unregistering the gt prior
>to unregistering the PMU. This means there is a small window
>of time in which the application can request metrics from the
>PMU, some of which are calling into the uapi engines list,
>while the engines are not available. In this case we can
>see null pointer dereferences.
>
>Fix this ordering in both the driver load and unload sequences.
>
>Additionally add a check for engine presence to prevent this
>NPD in the event this ordering is accidentally reversed. Print
>a debug message indicating when they aren't available.
>
>v1: Actually address the driver load/unload ordering issue
>
>Signed-off-by: Stuart Summers <stuart.summers@intel.com>
>---

I thought this is likely happening because intel_gpu_top is running in 
the background when i915 is unloaded. I tried a quick repro, I don't see 
the unload succeed ("fatal module in use", not sure if this was a 
partial unload), but when I try to kill intel_gpu_top, I get an NPD.  
This is in the event disable path - i915_pmu_event_stop -> 
i915_pmu_disable.

It's likely that you are seeing a different path (unload) leading to the 
same issue.

I think in i915_pmu_disable/disable should be aware of event->hw.state 
and or pmu->closed states before accessing the event. Maybe like,

if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event)) {

@Tvrtko, wondering if this case is tested by igt@perf_pmu@module-unload. 
I am not clear if we should use event->hw.state or pmu->closed here and 
if/how they are related. IMO, for this issue, the engine check is good 
enough too, so we don't really need the pmu state checks.  Thoughts?

Regards,
Umesh

> drivers/gpu/drm/i915/i915_driver.c | 11 ++---
> drivers/gpu/drm/i915/i915_pmu.c    | 72 +++++++++++++++++-------------
> 2 files changed, 48 insertions(+), 35 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
>index deb8a8b76965..ee4dcb85d206 100644
>--- a/drivers/gpu/drm/i915/i915_driver.c
>+++ b/drivers/gpu/drm/i915/i915_driver.c
>@@ -717,7 +717,6 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
> 	struct drm_device *dev = &dev_priv->drm;
>
> 	i915_gem_driver_register(dev_priv);
>-	i915_pmu_register(dev_priv);
>
> 	intel_vgpu_register(dev_priv);
>
>@@ -731,11 +730,12 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
> 	i915_debugfs_register(dev_priv);
> 	i915_setup_sysfs(dev_priv);
>
>+	intel_gt_driver_register(to_gt(dev_priv));
>+
> 	/* Depends on sysfs having been initialized */
>+	i915_pmu_register(dev_priv);
> 	i915_perf_register(dev_priv);
>
>-	intel_gt_driver_register(to_gt(dev_priv));
>-
> 	intel_display_driver_register(dev_priv);
>
> 	intel_power_domains_enable(dev_priv);
>@@ -762,11 +762,12 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv)
>
> 	intel_display_driver_unregister(dev_priv);
>
>-	intel_gt_driver_unregister(to_gt(dev_priv));
>-
> 	i915_perf_unregister(dev_priv);
>+	/* GT should be available until PMU is gone */
> 	i915_pmu_unregister(dev_priv);
>
>+	intel_gt_driver_unregister(to_gt(dev_priv));
>+
> 	i915_teardown_sysfs(dev_priv);
> 	drm_dev_unplug(&dev_priv->drm);
>
>diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
>index 958b37123bf1..796a1d8e36f2 100644
>--- a/drivers/gpu/drm/i915/i915_pmu.c
>+++ b/drivers/gpu/drm/i915/i915_pmu.c
>@@ -670,21 +670,28 @@ static void i915_pmu_enable(struct perf_event *event)
> 	if (is_engine_event(event)) {
> 		u8 sample = engine_event_sample(event);
> 		struct intel_engine_cs *engine;
>-
>-		engine = intel_engine_lookup_user(i915,
>-						  engine_event_class(event),
>-						  engine_event_instance(event));
>-
>-		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
>-			     I915_ENGINE_SAMPLE_COUNT);
>-		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
>-			     I915_ENGINE_SAMPLE_COUNT);
>-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
>-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
>-		GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
>-
>-		engine->pmu.enable |= BIT(sample);
>-		engine->pmu.enable_count[sample]++;
>+		u8 class = engine_event_class(event);
>+		u8 instance = engine_event_instance(event);
>+
>+		engine = intel_engine_lookup_user(i915, class, instance);
>+		if (engine) {
>+			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
>+				     I915_ENGINE_SAMPLE_COUNT);
>+			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
>+				     I915_ENGINE_SAMPLE_COUNT);
>+			GEM_BUG_ON(sample >=
>+				   ARRAY_SIZE(engine->pmu.enable_count));
>+			GEM_BUG_ON(sample >=
>+				   ARRAY_SIZE(engine->pmu.sample));
>+			GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
>+
>+			engine->pmu.enable |= BIT(sample);
>+			engine->pmu.enable_count[sample]++;
>+		} else {
>+			drm_dbg(&i915->drm,
>+				"Invalid engine event: { class:%d, inst:%d }\n",
>+				class, instance);
>+		}
> 	}
>
> 	spin_unlock_irqrestore(&pmu->lock, flags);
>@@ -714,21 +721,26 @@ static void i915_pmu_disable(struct perf_event *event)
> 	if (is_engine_event(event)) {
> 		u8 sample = engine_event_sample(event);
> 		struct intel_engine_cs *engine;
>-
>-		engine = intel_engine_lookup_user(i915,
>-						  engine_event_class(event),
>-						  engine_event_instance(event));
>-
>-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
>-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
>-		GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
>-
>-		/*
>-		 * Decrement the reference count and clear the enabled
>-		 * bitmask when the last listener on an event goes away.
>-		 */
>-		if (--engine->pmu.enable_count[sample] == 0)
>-			engine->pmu.enable &= ~BIT(sample);
>+		u8 class = engine_event_class(event);
>+		u8 instance = engine_event_instance(event);
>+
>+		engine = intel_engine_lookup_user(i915, class, instance);
>+		if (engine) {
>+			GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
>+			GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
>+			GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
>+
>+			/*
>+			 * Decrement the reference count and clear the enabled
>+			 * bitmask when the last listener on an event goes away.
>+			 */
>+			if (--engine->pmu.enable_count[sample] == 0)
>+				engine->pmu.enable &= ~BIT(sample);
>+		} else {
>+			drm_dbg(&i915->drm,
>+				"Invalid engine event: { class:%d, inst:%d }\n",
>+				class, instance);
>+		}
> 	}
>
> 	GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));
>-- 
>2.25.1
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-07-01  0:11 ` [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown Umesh Nerlige Ramappa
@ 2022-07-01  8:37   ` Tvrtko Ursulin
  2022-07-01 14:54     ` Summers, Stuart
  2022-07-01 18:09     ` Umesh Nerlige Ramappa
  0 siblings, 2 replies; 21+ messages in thread
From: Tvrtko Ursulin @ 2022-07-01  8:37 UTC (permalink / raw)
  To: Umesh Nerlige Ramappa, Stuart Summers; +Cc: intel-gfx


On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
> On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart Summers wrote:
>> In the driver teardown, we are unregistering the gt prior
>> to unregistering the PMU. This means there is a small window
>> of time in which the application can request metrics from the
>> PMU, some of which are calling into the uapi engines list,
>> while the engines are not available. In this case we can
>> see null pointer dereferences.
>>
>> Fix this ordering in both the driver load and unload sequences.
>>
>> Additionally add a check for engine presence to prevent this
>> NPD in the event this ordering is accidentally reversed. Print
>> a debug message indicating when they aren't available.
>>
>> v1: Actually address the driver load/unload ordering issue
>>
>> Signed-off-by: Stuart Summers <stuart.summers@intel.com>
>> ---
> 
> I thought this is likely happening because intel_gpu_top is running in 
> the background when i915 is unloaded. I tried a quick repro, I don't see 
> the unload succeed ("fatal module in use", not sure if this was a 
> partial unload), but when I try to kill intel_gpu_top, I get an NPD. 
> This is in the event disable path - i915_pmu_event_stop -> 
> i915_pmu_disable.

So i915 failed to unload (as expected - with perf events open we elevate 
the module ref count via i915_pmu_event_init -> drm_dev_get), then you 
quit intel_gpu_top and get NPD? On the engine lookup? With the 
re-ordered init/fini sequence as from this patch?

With elevated module count there shouldn't be any unloading happening so 
I am intrigued.

> It's likely that you are seeing a different path (unload) leading to the 
> same issue.
> 
> I think in i915_pmu_disable/disable should be aware of event->hw.state 
> and or pmu->closed states before accessing the event. Maybe like,
> 
> if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event)) {
> 
> @Tvrtko, wondering if this case is tested by igt@perf_pmu@module-unload. 

A bit yes. From what Stuart wrote it seems the test would need to be 
extended to cover the case where PMU is getting opened while module 
unload is in progress.

But the NPD you saw is for the moment confusing so I don't know what is 
happening.

> I am not clear if we should use event->hw.state or pmu->closed here and 
> if/how they are related. IMO, for this issue, the engine check is good 
> enough too, so we don't really need the pmu state checks.  Thoughts?

Engine check at the moment feels like papering.

Indeed as you say I think the pmu->closed might be the solution. Perhaps 
the race is as mentioned above. PMU open happening in parallel to unload..

If the sequence of events userspace triggers is:

   i915_pmu_event_init
   i915_pmu_event_start
   i915_pmu_enable
   i915_pmu_event_read

I guess pmu->closed can get set halfway in i915_pmu_event_init. What 
would be the effect of that.. We'd try to get a module reference while 
in the process of unloading. Which is probably very bad.. So possibly a 
final check on pmu->close is needed there. Ho hum.. can it be made safe 
is the question.

It doesn't explain the NPD on Ctrl-C though.. intel_gpu_top keeps the 
evens open all the time. So I think more info needed, for me at least.

Regards,

Tvrtko

> 
> Regards,
> Umesh
> 
>> drivers/gpu/drm/i915/i915_driver.c | 11 ++---
>> drivers/gpu/drm/i915/i915_pmu.c    | 72 +++++++++++++++++-------------
>> 2 files changed, 48 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_driver.c 
>> b/drivers/gpu/drm/i915/i915_driver.c
>> index deb8a8b76965..ee4dcb85d206 100644
>> --- a/drivers/gpu/drm/i915/i915_driver.c
>> +++ b/drivers/gpu/drm/i915/i915_driver.c
>> @@ -717,7 +717,6 @@ static void i915_driver_register(struct 
>> drm_i915_private *dev_priv)
>>     struct drm_device *dev = &dev_priv->drm;
>>
>>     i915_gem_driver_register(dev_priv);
>> -    i915_pmu_register(dev_priv);
>>
>>     intel_vgpu_register(dev_priv);
>>
>> @@ -731,11 +730,12 @@ static void i915_driver_register(struct 
>> drm_i915_private *dev_priv)
>>     i915_debugfs_register(dev_priv);
>>     i915_setup_sysfs(dev_priv);
>>
>> +    intel_gt_driver_register(to_gt(dev_priv));
>> +
>>     /* Depends on sysfs having been initialized */
>> +    i915_pmu_register(dev_priv);
>>     i915_perf_register(dev_priv);
>>
>> -    intel_gt_driver_register(to_gt(dev_priv));
>> -
>>     intel_display_driver_register(dev_priv);
>>
>>     intel_power_domains_enable(dev_priv);
>> @@ -762,11 +762,12 @@ static void i915_driver_unregister(struct 
>> drm_i915_private *dev_priv)
>>
>>     intel_display_driver_unregister(dev_priv);
>>
>> -    intel_gt_driver_unregister(to_gt(dev_priv));
>> -
>>     i915_perf_unregister(dev_priv);
>> +    /* GT should be available until PMU is gone */
>>     i915_pmu_unregister(dev_priv);
>>
>> +    intel_gt_driver_unregister(to_gt(dev_priv));
>> +
>>     i915_teardown_sysfs(dev_priv);
>>     drm_dev_unplug(&dev_priv->drm);
>>
>> diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
>> b/drivers/gpu/drm/i915/i915_pmu.c
>> index 958b37123bf1..796a1d8e36f2 100644
>> --- a/drivers/gpu/drm/i915/i915_pmu.c
>> +++ b/drivers/gpu/drm/i915/i915_pmu.c
>> @@ -670,21 +670,28 @@ static void i915_pmu_enable(struct perf_event 
>> *event)
>>     if (is_engine_event(event)) {
>>         u8 sample = engine_event_sample(event);
>>         struct intel_engine_cs *engine;
>> -
>> -        engine = intel_engine_lookup_user(i915,
>> -                          engine_event_class(event),
>> -                          engine_event_instance(event));
>> -
>> -        BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
>> -                 I915_ENGINE_SAMPLE_COUNT);
>> -        BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
>> -                 I915_ENGINE_SAMPLE_COUNT);
>> -        GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
>> -        GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
>> -        GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
>> -
>> -        engine->pmu.enable |= BIT(sample);
>> -        engine->pmu.enable_count[sample]++;
>> +        u8 class = engine_event_class(event);
>> +        u8 instance = engine_event_instance(event);
>> +
>> +        engine = intel_engine_lookup_user(i915, class, instance);
>> +        if (engine) {
>> +            BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
>> +                     I915_ENGINE_SAMPLE_COUNT);
>> +            BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
>> +                     I915_ENGINE_SAMPLE_COUNT);
>> +            GEM_BUG_ON(sample >=
>> +                   ARRAY_SIZE(engine->pmu.enable_count));
>> +            GEM_BUG_ON(sample >=
>> +                   ARRAY_SIZE(engine->pmu.sample));
>> +            GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
>> +
>> +            engine->pmu.enable |= BIT(sample);
>> +            engine->pmu.enable_count[sample]++;
>> +        } else {
>> +            drm_dbg(&i915->drm,
>> +                "Invalid engine event: { class:%d, inst:%d }\n",
>> +                class, instance);
>> +        }
>>     }
>>
>>     spin_unlock_irqrestore(&pmu->lock, flags);
>> @@ -714,21 +721,26 @@ static void i915_pmu_disable(struct perf_event 
>> *event)
>>     if (is_engine_event(event)) {
>>         u8 sample = engine_event_sample(event);
>>         struct intel_engine_cs *engine;
>> -
>> -        engine = intel_engine_lookup_user(i915,
>> -                          engine_event_class(event),
>> -                          engine_event_instance(event));
>> -
>> -        GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
>> -        GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
>> -        GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
>> -
>> -        /*
>> -         * Decrement the reference count and clear the enabled
>> -         * bitmask when the last listener on an event goes away.
>> -         */
>> -        if (--engine->pmu.enable_count[sample] == 0)
>> -            engine->pmu.enable &= ~BIT(sample);
>> +        u8 class = engine_event_class(event);
>> +        u8 instance = engine_event_instance(event);
>> +
>> +        engine = intel_engine_lookup_user(i915, class, instance);
>> +        if (engine) {
>> +            GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
>> +            GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
>> +            GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
>> +
>> +            /*
>> +             * Decrement the reference count and clear the enabled
>> +             * bitmask when the last listener on an event goes away.
>> +             */
>> +            if (--engine->pmu.enable_count[sample] == 0)
>> +                engine->pmu.enable &= ~BIT(sample);
>> +        } else {
>> +            drm_dbg(&i915->drm,
>> +                "Invalid engine event: { class:%d, inst:%d }\n",
>> +                class, instance);
>> +        }
>>     }
>>
>>     GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));
>> -- 
>> 2.25.1
>>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix NPD in PMU during driver teardown (rev2)
  2022-06-30 21:00 [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown Stuart Summers
  2022-06-30 21:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix NPD in PMU during driver teardown (rev2) Patchwork
  2022-07-01  0:11 ` [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown Umesh Nerlige Ramappa
@ 2022-07-01 13:54 ` Patchwork
  2 siblings, 0 replies; 21+ messages in thread
From: Patchwork @ 2022-07-01 13:54 UTC (permalink / raw)
  To: Stuart Summers; +Cc: intel-gfx

[-- Attachment #1: Type: text/plain, Size: 67385 bytes --]

== Series Details ==

Series: drm/i915: Fix NPD in PMU during driver teardown (rev2)
URL   : https://patchwork.freedesktop.org/series/105790/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11835_full -> Patchwork_105790v2_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_105790v2_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_105790v2_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (13 -> 13)
------------------------------

  No changes in participating hosts

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_105790v2_full:

### IGT changes ###

#### Possible regressions ####

  * igt@kms_cursor_legacy@cursor-vs-flip@atomic-transitions-varying-size:
    - shard-skl:          NOTRUN -> [INCOMPLETE][1]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl7/igt@kms_cursor_legacy@cursor-vs-flip@atomic-transitions-varying-size.html

  

### Piglit changes ###

#### Possible regressions ####

  * spec@glsl-4.20@execution@vs_in@vs-input-float_mat2-double_dmat4x2_array2-position:
    - pig-glk-j5005:      NOTRUN -> [CRASH][2] +1 similar issue
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/pig-glk-j5005/spec@glsl-4.20@execution@vs_in@vs-input-float_mat2-double_dmat4x2_array2-position.html

  
Known issues
------------

  Here are the changes found in Patchwork_105790v2_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_create@create-massive:
    - shard-apl:          NOTRUN -> [DMESG-WARN][3] ([i915#4991])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl1/igt@gem_create@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
    - shard-kbl:          [PASS][4] -> [DMESG-WARN][5] ([i915#180]) +5 similar issues
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl6/igt@gem_ctx_isolation@preservation-s3@vcs0.html
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl7/igt@gem_ctx_isolation@preservation-s3@vcs0.html

  * igt@gem_ctx_persistence@hang:
    - shard-skl:          NOTRUN -> [SKIP][6] ([fdo#109271]) +120 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl7/igt@gem_ctx_persistence@hang.html

  * igt@gem_ctx_persistence@smoketest:
    - shard-kbl:          [PASS][7] -> [INCOMPLETE][8] ([i915#6310])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl1/igt@gem_ctx_persistence@smoketest.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@gem_ctx_persistence@smoketest.html

  * igt@gem_eio@in-flight-contexts-10ms:
    - shard-tglb:         [PASS][9] -> [TIMEOUT][10] ([i915#3063])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglb2/igt@gem_eio@in-flight-contexts-10ms.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb1/igt@gem_eio@in-flight-contexts-10ms.html

  * igt@gem_eio@unwedge-stress:
    - shard-tglb:         [PASS][11] -> [FAIL][12] ([i915#5784])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglb7/igt@gem_eio@unwedge-stress.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb3/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_balancer@parallel:
    - shard-iclb:         [PASS][13] -> [SKIP][14] ([i915#4525])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb2/igt@gem_exec_balancer@parallel.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb8/igt@gem_exec_balancer@parallel.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
    - shard-glk:          NOTRUN -> [FAIL][15] ([i915#2842])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk8/igt@gem_exec_fair@basic-none-solo@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
    - shard-kbl:          [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@gem_exec_fair@basic-pace@vcs0.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl1/igt@gem_exec_fair@basic-pace@vcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
    - shard-iclb:         [PASS][18] -> [FAIL][19] ([i915#2849])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb6/igt@gem_exec_fair@basic-throttle@rcs0.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb6/igt@gem_exec_fair@basic-throttle@rcs0.html

  * igt@gem_exec_schedule@pi-distinct-iova@vecs0:
    - shard-glk:          [PASS][20] -> [INCOMPLETE][21] ([i915#6310])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-glk9/igt@gem_exec_schedule@pi-distinct-iova@vecs0.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk8/igt@gem_exec_schedule@pi-distinct-iova@vecs0.html

  * igt@gem_huc_copy@huc-copy:
    - shard-apl:          NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#2190])
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl8/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@heavy-verify-multi:
    - shard-apl:          NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#4613]) +2 similar issues
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl8/igt@gem_lmem_swapping@heavy-verify-multi.html

  * igt@gem_lmem_swapping@parallel-random-verify:
    - shard-kbl:          NOTRUN -> [SKIP][24] ([fdo#109271] / [i915#4613]) +2 similar issues
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@gem_lmem_swapping@parallel-random-verify.html

  * igt@gem_lmem_swapping@parallel-random-verify-ccs:
    - shard-skl:          NOTRUN -> [SKIP][25] ([fdo#109271] / [i915#4613]) +1 similar issue
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl1/igt@gem_lmem_swapping@parallel-random-verify-ccs.html

  * igt@gem_pxp@protected-encrypted-src-copy-not-readible:
    - shard-tglb:         NOTRUN -> [SKIP][26] ([i915#4270]) +1 similar issue
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@gem_pxp@protected-encrypted-src-copy-not-readible.html

  * igt@gem_softpin@evict-single-offset:
    - shard-apl:          NOTRUN -> [FAIL][27] ([i915#4171])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl8/igt@gem_softpin@evict-single-offset.html
    - shard-glk:          NOTRUN -> [FAIL][28] ([i915#4171])
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk1/igt@gem_softpin@evict-single-offset.html

  * igt@gem_userptr_blits@dmabuf-sync:
    - shard-apl:          NOTRUN -> [SKIP][29] ([fdo#109271] / [i915#3323])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl4/igt@gem_userptr_blits@dmabuf-sync.html
    - shard-kbl:          NOTRUN -> [SKIP][30] ([fdo#109271] / [i915#3323])
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@gem_userptr_blits@dmabuf-sync.html

  * igt@gem_userptr_blits@dmabuf-unsync:
    - shard-tglb:         NOTRUN -> [SKIP][31] ([i915#3297])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@gem_userptr_blits@dmabuf-unsync.html

  * igt@gem_userptr_blits@input-checking:
    - shard-kbl:          NOTRUN -> [DMESG-WARN][32] ([i915#4991])
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl4/igt@gem_userptr_blits@input-checking.html
    - shard-tglb:         NOTRUN -> [DMESG-WARN][33] ([i915#4991])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@gem_userptr_blits@input-checking.html

  * igt@gem_userptr_blits@vma-merge:
    - shard-skl:          NOTRUN -> [FAIL][34] ([i915#3318])
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl1/igt@gem_userptr_blits@vma-merge.html

  * igt@gen3_render_tiledx_blits:
    - shard-tglb:         NOTRUN -> [SKIP][35] ([fdo#109289]) +1 similar issue
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@gen3_render_tiledx_blits.html

  * igt@gen9_exec_parse@allowed-single:
    - shard-apl:          [PASS][36] -> [DMESG-WARN][37] ([i915#5566] / [i915#716])
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl3/igt@gen9_exec_parse@allowed-single.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl8/igt@gen9_exec_parse@allowed-single.html
    - shard-glk:          [PASS][38] -> [DMESG-WARN][39] ([i915#5566] / [i915#716])
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-glk3/igt@gen9_exec_parse@allowed-single.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk3/igt@gen9_exec_parse@allowed-single.html

  * igt@gen9_exec_parse@bb-oversize:
    - shard-tglb:         NOTRUN -> [SKIP][40] ([i915#2527] / [i915#2856])
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@gen9_exec_parse@bb-oversize.html

  * igt@i915_pm_dc@dc6-dpms:
    - shard-tglb:         NOTRUN -> [FAIL][41] ([i915#3989] / [i915#454])
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@i915_pm_dc@dc6-dpms.html
    - shard-kbl:          NOTRUN -> [FAIL][42] ([i915#454])
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl4/igt@i915_pm_dc@dc6-dpms.html

  * igt@i915_pm_dc@dc6-psr:
    - shard-iclb:         [PASS][43] -> [FAIL][44] ([i915#454])
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb2/igt@i915_pm_dc@dc6-psr.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb4/igt@i915_pm_dc@dc6-psr.html

  * igt@i915_pm_rpm@dpms-lpsp:
    - shard-kbl:          NOTRUN -> [SKIP][45] ([fdo#109271]) +160 similar issues
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@i915_pm_rpm@dpms-lpsp.html

  * igt@i915_selftest@live@hangcheck:
    - shard-snb:          [PASS][46] -> [INCOMPLETE][47] ([i915#3921])
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-snb6/igt@i915_selftest@live@hangcheck.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-snb2/igt@i915_selftest@live@hangcheck.html

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-b-edp-1:
    - shard-skl:          [PASS][48] -> [FAIL][49] ([i915#2521])
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-skl7/igt@kms_async_flips@alternate-sync-async-flip@pipe-b-edp-1.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl1/igt@kms_async_flips@alternate-sync-async-flip@pipe-b-edp-1.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
    - shard-tglb:         NOTRUN -> [SKIP][50] ([i915#5286]) +1 similar issue
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html

  * igt@kms_big_fb@linear-8bpp-rotate-90:
    - shard-tglb:         NOTRUN -> [SKIP][51] ([fdo#111614]) +1 similar issue
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_big_fb@linear-8bpp-rotate-90.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-async-flip:
    - shard-skl:          NOTRUN -> [FAIL][52] ([i915#3743]) +2 similar issues
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl1/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-async-flip.html

  * igt@kms_big_fb@yf-tiled-addfb-size-overflow:
    - shard-tglb:         NOTRUN -> [SKIP][53] ([fdo#111615])
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_big_fb@yf-tiled-addfb-size-overflow.html

  * igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_mc_ccs:
    - shard-apl:          NOTRUN -> [SKIP][54] ([fdo#109271] / [i915#3886]) +4 similar issues
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl4/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
    - shard-glk:          NOTRUN -> [SKIP][55] ([fdo#109271] / [i915#3886])
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk1/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_ccs:
    - shard-tglb:         NOTRUN -> [SKIP][56] ([i915#3689]) +1 similar issue
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_ccs.html

  * igt@kms_ccs@pipe-b-crc-primary-basic-4_tiled_dg2_rc_ccs_cc:
    - shard-tglb:         NOTRUN -> [SKIP][57] ([i915#6095]) +2 similar issues
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_ccs@pipe-b-crc-primary-basic-4_tiled_dg2_rc_ccs_cc.html

  * igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
    - shard-tglb:         NOTRUN -> [SKIP][58] ([i915#3689] / [i915#3886])
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs:
    - shard-skl:          NOTRUN -> [SKIP][59] ([fdo#109271] / [i915#3886]) +4 similar issues
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl7/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs:
    - shard-kbl:          NOTRUN -> [SKIP][60] ([fdo#109271] / [i915#3886]) +9 similar issues
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl7/igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-c-crc-sprite-planes-basic-4_tiled_dg2_rc_ccs:
    - shard-glk:          NOTRUN -> [SKIP][61] ([fdo#109271]) +28 similar issues
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk1/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-4_tiled_dg2_rc_ccs.html

  * igt@kms_ccs@pipe-c-random-ccs-data-4_tiled_dg2_rc_ccs:
    - shard-tglb:         NOTRUN -> [SKIP][62] ([i915#3689] / [i915#6095])
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_ccs@pipe-c-random-ccs-data-4_tiled_dg2_rc_ccs.html

  * igt@kms_ccs@pipe-d-crc-primary-basic-yf_tiled_ccs:
    - shard-tglb:         NOTRUN -> [SKIP][63] ([fdo#111615] / [i915#3689]) +1 similar issue
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_ccs@pipe-d-crc-primary-basic-yf_tiled_ccs.html

  * igt@kms_color_chamelium@pipe-a-ctm-limited-range:
    - shard-tglb:         NOTRUN -> [SKIP][64] ([fdo#109284] / [fdo#111827]) +3 similar issues
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_color_chamelium@pipe-a-ctm-limited-range.html

  * igt@kms_color_chamelium@pipe-a-degamma:
    - shard-kbl:          NOTRUN -> [SKIP][65] ([fdo#109271] / [fdo#111827]) +13 similar issues
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl4/igt@kms_color_chamelium@pipe-a-degamma.html

  * igt@kms_color_chamelium@pipe-b-ctm-green-to-red:
    - shard-skl:          NOTRUN -> [SKIP][66] ([fdo#109271] / [fdo#111827]) +10 similar issues
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl7/igt@kms_color_chamelium@pipe-b-ctm-green-to-red.html

  * igt@kms_color_chamelium@pipe-c-ctm-max:
    - shard-apl:          NOTRUN -> [SKIP][67] ([fdo#109271] / [fdo#111827]) +11 similar issues
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl8/igt@kms_color_chamelium@pipe-c-ctm-max.html

  * igt@kms_content_protection@atomic:
    - shard-apl:          NOTRUN -> [TIMEOUT][68] ([i915#1319])
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl1/igt@kms_content_protection@atomic.html

  * igt@kms_content_protection@uevent:
    - shard-tglb:         NOTRUN -> [SKIP][69] ([i915#1063])
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_content_protection@uevent.html

  * igt@kms_cursor_legacy@short-busy-flip-before-cursor:
    - shard-tglb:         NOTRUN -> [SKIP][70] ([i915#4103])
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_cursor_legacy@short-busy-flip-before-cursor.html

  * igt@kms_draw_crc@draw-method-xrgb8888-blt-4tiled:
    - shard-tglb:         NOTRUN -> [SKIP][71] ([i915#5287])
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_draw_crc@draw-method-xrgb8888-blt-4tiled.html

  * igt@kms_flip@2x-busy-flip:
    - shard-tglb:         NOTRUN -> [SKIP][72] ([fdo#109274] / [fdo#111825])
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_flip@2x-busy-flip.html

  * igt@kms_flip@2x-flip-vs-expired-vblank@ac-hdmi-a1-hdmi-a2:
    - shard-glk:          [PASS][73] -> [FAIL][74] ([i915#79]) +1 similar issue
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vblank@ac-hdmi-a1-hdmi-a2.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank@ac-hdmi-a1-hdmi-a2.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
    - shard-skl:          [PASS][75] -> [FAIL][76] ([i915#79])
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1:
    - shard-skl:          [PASS][77] -> [FAIL][78] ([i915#2122])
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-dp1:
    - shard-apl:          [PASS][79] -> [FAIL][80] ([i915#79])
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl4/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-dp1.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl2/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-dp1.html

  * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-downscaling:
    - shard-iclb:         [PASS][81] -> [SKIP][82] ([i915#3701])
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb5/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-downscaling.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-downscaling.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-snb:          [PASS][83] -> [DMESG-WARN][84] ([i915#5090])
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-snb6/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-snb6/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-indfb-draw-blt:
    - shard-tglb:         NOTRUN -> [SKIP][85] ([fdo#109280] / [fdo#111825]) +8 similar issues
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-indfb-draw-blt.html

  * igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1:
    - shard-apl:          [PASS][86] -> [DMESG-WARN][87] ([i915#180])
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl3/igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1.html
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl3/igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1.html

  * igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes:
    - shard-kbl:          NOTRUN -> [DMESG-WARN][88] ([i915#180]) +1 similar issue
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes.html

  * igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
    - shard-glk:          NOTRUN -> [FAIL][89] ([fdo#108145] / [i915#265])
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk8/igt@kms_plane_alpha_blend@pipe-b-alpha-basic.html

  * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
    - shard-apl:          NOTRUN -> [FAIL][90] ([fdo#108145] / [i915#265]) +1 similar issue
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl4/igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb.html
    - shard-kbl:          NOTRUN -> [FAIL][91] ([fdo#108145] / [i915#265])
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb.html

  * igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb:
    - shard-kbl:          NOTRUN -> [FAIL][92] ([i915#265])
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl7/igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
    - shard-skl:          NOTRUN -> [FAIL][93] ([fdo#108145] / [i915#265])
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max.html

  * igt@kms_plane_lowres@tiling-y@pipe-c-edp-1:
    - shard-tglb:         NOTRUN -> [SKIP][94] ([i915#3536]) +3 similar issues
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_plane_lowres@tiling-y@pipe-c-edp-1.html

  * igt@kms_plane_lowres@tiling-yf:
    - shard-tglb:         NOTRUN -> [SKIP][95] ([fdo#112054])
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb7/igt@kms_plane_lowres@tiling-yf.html

  * igt@kms_plane_lowres@tiling-yf@pipe-a-edp-1:
    - shard-iclb:         NOTRUN -> [SKIP][96] ([i915#3536]) +2 similar issues
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb3/igt@kms_plane_lowres@tiling-yf@pipe-a-edp-1.html

  * igt@kms_plane_scaling@invalid-num-scalers@pipe-a-edp-1-invalid-num-scalers:
    - shard-skl:          NOTRUN -> [SKIP][97] ([fdo#109271] / [i915#5776]) +2 similar issues
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl7/igt@kms_plane_scaling@invalid-num-scalers@pipe-a-edp-1-invalid-num-scalers.html

  * igt@kms_plane_scaling@plane-upscale-with-rotation-20x20@pipe-c-edp-1:
    - shard-tglb:         NOTRUN -> [SKIP][98] ([i915#5176]) +7 similar issues
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_plane_scaling@plane-upscale-with-rotation-20x20@pipe-c-edp-1.html

  * igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-b-edp-1:
    - shard-iclb:         [PASS][99] -> [SKIP][100] ([i915#5235]) +2 similar issues
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb1/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-b-edp-1.html
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb2/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-b-edp-1.html

  * igt@kms_psr2_sf@cursor-plane-move-continuous-sf:
    - shard-kbl:          NOTRUN -> [SKIP][101] ([fdo#109271] / [i915#658]) +2 similar issues
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl7/igt@kms_psr2_sf@cursor-plane-move-continuous-sf.html

  * igt@kms_psr2_sf@cursor-plane-update-sf:
    - shard-tglb:         NOTRUN -> [SKIP][102] ([i915#2920])
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_psr2_sf@cursor-plane-update-sf.html

  * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area:
    - shard-skl:          NOTRUN -> [SKIP][103] ([fdo#109271] / [i915#658]) +2 similar issues
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl7/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area.html
    - shard-apl:          NOTRUN -> [SKIP][104] ([fdo#109271] / [i915#658]) +2 similar issues
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl6/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area.html

  * igt@kms_psr2_su@frontbuffer-xrgb8888:
    - shard-iclb:         [PASS][105] -> [SKIP][106] ([fdo#109642] / [fdo#111068] / [i915#658])
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb2/igt@kms_psr2_su@frontbuffer-xrgb8888.html
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb1/igt@kms_psr2_su@frontbuffer-xrgb8888.html

  * igt@kms_psr@primary_page_flip:
    - shard-apl:          NOTRUN -> [SKIP][107] ([fdo#109271]) +147 similar issues
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl8/igt@kms_psr@primary_page_flip.html

  * igt@kms_psr@psr2_primary_blt:
    - shard-tglb:         NOTRUN -> [FAIL][108] ([i915#132] / [i915#3467])
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_psr@psr2_primary_blt.html

  * igt@kms_psr@psr2_primary_page_flip:
    - shard-iclb:         [PASS][109] -> [SKIP][110] ([fdo#109441]) +1 similar issue
   [109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
   [110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb8/igt@kms_psr@psr2_primary_page_flip.html

  * igt@kms_setmode@invalid-clone-single-crtc-stealing:
    - shard-tglb:         NOTRUN -> [SKIP][111] ([i915#3555])
   [111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@kms_setmode@invalid-clone-single-crtc-stealing.html

  * igt@kms_vblank@pipe-d-wait-idle:
    - shard-apl:          NOTRUN -> [SKIP][112] ([fdo#109271] / [i915#533])
   [112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl8/igt@kms_vblank@pipe-d-wait-idle.html
    - shard-kbl:          NOTRUN -> [SKIP][113] ([fdo#109271] / [i915#533])
   [113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@kms_vblank@pipe-d-wait-idle.html

  * igt@kms_writeback@writeback-invalid-parameters:
    - shard-apl:          NOTRUN -> [SKIP][114] ([fdo#109271] / [i915#2437])
   [114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl4/igt@kms_writeback@writeback-invalid-parameters.html
    - shard-kbl:          NOTRUN -> [SKIP][115] ([fdo#109271] / [i915#2437])
   [115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@kms_writeback@writeback-invalid-parameters.html

  * igt@prime_mmap_coherency@ioctl-errors:
    - shard-apl:          [PASS][116] -> [DMESG-FAIL][117] ([i915#6310])
   [116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl7/igt@prime_mmap_coherency@ioctl-errors.html
   [117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl7/igt@prime_mmap_coherency@ioctl-errors.html

  * igt@prime_nv_pcopy@test3_2:
    - shard-tglb:         NOTRUN -> [SKIP][118] ([fdo#109291])
   [118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@prime_nv_pcopy@test3_2.html

  * igt@sw_sync@sync_multi_timeline_wait:
    - shard-skl:          NOTRUN -> [FAIL][119] ([i915#6140]) +1 similar issue
   [119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl7/igt@sw_sync@sync_multi_timeline_wait.html
    - shard-apl:          NOTRUN -> [FAIL][120] ([i915#6140]) +1 similar issue
   [120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl6/igt@sw_sync@sync_multi_timeline_wait.html

  * igt@sysfs_clients@busy:
    - shard-apl:          NOTRUN -> [SKIP][121] ([fdo#109271] / [i915#2994]) +2 similar issues
   [121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl4/igt@sysfs_clients@busy.html

  * igt@sysfs_clients@fair-0:
    - shard-kbl:          NOTRUN -> [SKIP][122] ([fdo#109271] / [i915#2994]) +3 similar issues
   [122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl4/igt@sysfs_clients@fair-0.html

  * igt@sysfs_clients@sema-10:
    - shard-glk:          NOTRUN -> [SKIP][123] ([fdo#109271] / [i915#2994])
   [123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk8/igt@sysfs_clients@sema-10.html

  
#### Possible fixes ####

  * igt@gem_ctx_persistence@engines-hang@bcs0:
    - {shard-rkl}:        [SKIP][124] ([i915#6252]) -> [PASS][125]
   [124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-5/igt@gem_ctx_persistence@engines-hang@bcs0.html
   [125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-1/igt@gem_ctx_persistence@engines-hang@bcs0.html

  * igt@gem_ctx_persistence@engines-hostile@bcs0:
    - {shard-dg1}:        [FAIL][126] ([i915#4883]) -> [PASS][127] +1 similar issue
   [126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-dg1-18/igt@gem_ctx_persistence@engines-hostile@bcs0.html
   [127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-dg1-16/igt@gem_ctx_persistence@engines-hostile@bcs0.html

  * igt@gem_ctx_persistence@smoketest:
    - shard-glk:          [INCOMPLETE][128] ([i915#6310]) -> [PASS][129] +1 similar issue
   [128]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-glk6/igt@gem_ctx_persistence@smoketest.html
   [129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk8/igt@gem_ctx_persistence@smoketest.html

  * igt@gem_eio@in-flight-contexts-1us:
    - shard-tglb:         [TIMEOUT][130] ([i915#3063]) -> [PASS][131]
   [130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglb7/igt@gem_eio@in-flight-contexts-1us.html
   [131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb1/igt@gem_eio@in-flight-contexts-1us.html

  * igt@gem_eio@in-flight-suspend:
    - shard-snb:          [SKIP][132] ([fdo#109271]) -> [PASS][133]
   [132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-snb5/igt@gem_eio@in-flight-suspend.html
   [133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-snb4/igt@gem_eio@in-flight-suspend.html

  * igt@gem_eio@kms:
    - shard-tglb:         [FAIL][134] ([i915#5784]) -> [PASS][135]
   [134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglb5/igt@gem_eio@kms.html
   [135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb7/igt@gem_eio@kms.html

  * igt@gem_eio@unwedge-stress:
    - {shard-rkl}:        [TIMEOUT][136] ([i915#3063]) -> [PASS][137]
   [136]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@gem_eio@unwedge-stress.html
   [137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-5/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_balancer@parallel-keep-submit-fence:
    - shard-iclb:         [SKIP][138] ([i915#4525]) -> [PASS][139]
   [138]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb7/igt@gem_exec_balancer@parallel-keep-submit-fence.html
   [139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb1/igt@gem_exec_balancer@parallel-keep-submit-fence.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
    - {shard-tglu}:       [FAIL][140] ([i915#2842]) -> [PASS][141] +1 similar issue
   [140]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglu-6/igt@gem_exec_fair@basic-none-share@rcs0.html
   [141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglu-5/igt@gem_exec_fair@basic-none-share@rcs0.html
    - shard-iclb:         [FAIL][142] ([i915#2842]) -> [PASS][143]
   [142]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb6/igt@gem_exec_fair@basic-none-share@rcs0.html
   [143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb4/igt@gem_exec_fair@basic-none-share@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
    - shard-glk:          [FAIL][144] ([i915#2842]) -> [PASS][145] +1 similar issue
   [144]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-glk2/igt@gem_exec_fair@basic-pace-share@rcs0.html
   [145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk5/igt@gem_exec_fair@basic-pace-share@rcs0.html
    - shard-tglb:         [FAIL][146] ([i915#2842]) -> [PASS][147]
   [146]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglb3/igt@gem_exec_fair@basic-pace-share@rcs0.html
   [147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb2/igt@gem_exec_fair@basic-pace-share@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
    - shard-kbl:          [FAIL][148] ([i915#2842]) -> [PASS][149] +3 similar issues
   [148]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@gem_exec_fair@basic-pace@vecs0.html
   [149]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl1/igt@gem_exec_fair@basic-pace@vecs0.html

  * igt@gem_exec_reloc@basic-write-gtt:
    - {shard-rkl}:        [SKIP][150] ([i915#3281]) -> [PASS][151] +1 similar issue
   [150]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@gem_exec_reloc@basic-write-gtt.html
   [151]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-5/igt@gem_exec_reloc@basic-write-gtt.html

  * igt@gem_exec_whisper@basic-queues-forked-all:
    - shard-glk:          [DMESG-WARN][152] ([i915#118]) -> [PASS][153]
   [152]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-glk9/igt@gem_exec_whisper@basic-queues-forked-all.html
   [153]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk6/igt@gem_exec_whisper@basic-queues-forked-all.html

  * igt@gem_huc_copy@huc-copy:
    - shard-tglb:         [SKIP][154] ([i915#2190]) -> [PASS][155]
   [154]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglb7/igt@gem_huc_copy@huc-copy.html
   [155]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb1/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@smem-oom@lmem0:
    - {shard-dg1}:        [DMESG-WARN][156] ([i915#4936]) -> [PASS][157]
   [156]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-dg1-13/igt@gem_lmem_swapping@smem-oom@lmem0.html
   [157]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-dg1-12/igt@gem_lmem_swapping@smem-oom@lmem0.html

  * igt@gem_tiled_pread_pwrite:
    - {shard-rkl}:        [SKIP][158] ([i915#3282]) -> [PASS][159]
   [158]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@gem_tiled_pread_pwrite.html
   [159]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-5/igt@gem_tiled_pread_pwrite.html

  * igt@gen9_exec_parse@bb-large:
    - {shard-rkl}:        [SKIP][160] ([i915#2527]) -> [PASS][161]
   [160]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@gen9_exec_parse@bb-large.html
   [161]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-5/igt@gen9_exec_parse@bb-large.html

  * igt@i915_pm_dc@dc5-psr:
    - {shard-rkl}:        [SKIP][162] ([i915#658]) -> [PASS][163] +1 similar issue
   [162]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@i915_pm_dc@dc5-psr.html
   [163]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@i915_pm_dc@dc5-psr.html

  * igt@i915_pm_rpm@dpms-lpsp:
    - {shard-rkl}:        [SKIP][164] ([i915#1397]) -> [PASS][165] +1 similar issue
   [164]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-5/igt@i915_pm_rpm@dpms-lpsp.html
   [165]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@i915_pm_rpm@dpms-lpsp.html

  * igt@i915_pm_rpm@system-suspend-modeset:
    - {shard-rkl}:        [SKIP][166] ([fdo#109308]) -> [PASS][167]
   [166]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@i915_pm_rpm@system-suspend-modeset.html
   [167]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@i915_pm_rpm@system-suspend-modeset.html

  * igt@i915_suspend@fence-restore-untiled:
    - shard-kbl:          [DMESG-WARN][168] ([i915#180]) -> [PASS][169] +5 similar issues
   [168]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@i915_suspend@fence-restore-untiled.html
   [169]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl4/igt@i915_suspend@fence-restore-untiled.html

  * igt@kms_color@pipe-b-ctm-red-to-blue:
    - {shard-rkl}:        [SKIP][170] ([i915#1149] / [i915#1849] / [i915#4070] / [i915#4098]) -> [PASS][171] +1 similar issue
   [170]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@kms_color@pipe-b-ctm-red-to-blue.html
   [171]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@kms_color@pipe-b-ctm-red-to-blue.html

  * igt@kms_color@pipe-d-ctm-max:
    - {shard-dg1}:        [SKIP][172] ([i915#1836]) -> [PASS][173]
   [172]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-dg1-16/igt@kms_color@pipe-d-ctm-max.html
   [173]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-dg1-13/igt@kms_color@pipe-d-ctm-max.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
    - shard-glk:          [FAIL][174] ([i915#2346]) -> [PASS][175] +1 similar issue
   [174]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-glk9/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions.html
   [175]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk6/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions.html

  * igt@kms_draw_crc@draw-method-xrgb2101010-render-ytiled:
    - {shard-rkl}:        [SKIP][176] ([fdo#111314] / [i915#4098] / [i915#4369]) -> [PASS][177] +6 similar issues
   [176]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@kms_draw_crc@draw-method-xrgb2101010-render-ytiled.html
   [177]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@kms_draw_crc@draw-method-xrgb2101010-render-ytiled.html

  * igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a1:
    - shard-glk:          [FAIL][178] ([i915#79]) -> [PASS][179]
   [178]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-glk3/igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a1.html
   [179]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk7/igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a1.html

  * igt@kms_flip@flip-vs-suspend@a-dp1:
    - shard-apl:          [DMESG-WARN][180] ([i915#180]) -> [PASS][181] +5 similar issues
   [180]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl3/igt@kms_flip@flip-vs-suspend@a-dp1.html
   [181]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl6/igt@kms_flip@flip-vs-suspend@a-dp1.html

  * igt@kms_flip@flip-vs-suspend@b-edp1:
    - shard-skl:          [INCOMPLETE][182] ([i915#4839]) -> [PASS][183]
   [182]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-skl3/igt@kms_flip@flip-vs-suspend@b-edp1.html
   [183]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl7/igt@kms_flip@flip-vs-suspend@b-edp1.html

  * igt@kms_flip@flip-vs-suspend@b-vga1:
    - shard-snb:          [DMESG-WARN][184] ([i915#5090]) -> [PASS][185]
   [184]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-snb5/igt@kms_flip@flip-vs-suspend@b-vga1.html
   [185]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-snb4/igt@kms_flip@flip-vs-suspend@b-vga1.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-hdmi-a1:
    - shard-glk:          [FAIL][186] ([i915#2122]) -> [PASS][187]
   [186]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-glk5/igt@kms_flip@plain-flip-fb-recreate-interruptible@b-hdmi-a1.html
   [187]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk1/igt@kms_flip@plain-flip-fb-recreate-interruptible@b-hdmi-a1.html

  * igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1:
    - shard-skl:          [FAIL][188] ([i915#2122]) -> [PASS][189] +2 similar issues
   [188]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-skl9/igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1.html
   [189]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl1/igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1.html

  * igt@kms_flip@wf_vblank-ts-check-interruptible@c-hdmi-a1:
    - {shard-dg1}:        [FAIL][190] -> [PASS][191] +4 similar issues
   [190]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-dg1-16/igt@kms_flip@wf_vblank-ts-check-interruptible@c-hdmi-a1.html
   [191]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-dg1-13/igt@kms_flip@wf_vblank-ts-check-interruptible@c-hdmi-a1.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling:
    - shard-glk:          [FAIL][192] ([i915#4911]) -> [PASS][193]
   [192]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html
   [193]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk5/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render:
    - {shard-dg1}:        [SKIP][194] ([i915#5721]) -> [PASS][195]
   [194]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-dg1-16/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render.html
   [195]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-dg1-13/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
    - {shard-rkl}:        [SKIP][196] ([i915#1849] / [i915#4098]) -> [PASS][197] +29 similar issues
   [196]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt.html
   [197]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt.html

  * igt@kms_invalid_mode@zero-clock:
    - {shard-rkl}:        [SKIP][198] ([i915#4278]) -> [PASS][199]
   [198]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@kms_invalid_mode@zero-clock.html
   [199]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@kms_invalid_mode@zero-clock.html

  * igt@kms_lease@empty_lease:
    - {shard-dg1}:        [WARN][200] ([i915#5971]) -> [PASS][201]
   [200]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-dg1-16/igt@kms_lease@empty_lease.html
   [201]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-dg1-13/igt@kms_lease@empty_lease.html

  * igt@kms_plane@plane-panning-top-left@pipe-b-planes:
    - {shard-rkl}:        [SKIP][202] ([i915#1849] / [i915#3558]) -> [PASS][203] +1 similar issue
   [202]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-5/igt@kms_plane@plane-panning-top-left@pipe-b-planes.html
   [203]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@kms_plane@plane-panning-top-left@pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
    - {shard-rkl}:        [SKIP][204] ([i915#1849] / [i915#4070] / [i915#4098]) -> [PASS][205]
   [204]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html
   [205]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
    - shard-skl:          [FAIL][206] ([fdo#108145] / [i915#265]) -> [PASS][207]
   [206]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-skl10/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
   [207]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl6/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-d-hdmi-a-1:
    - {shard-dg1}:        [SKIP][208] ([i915#5176]) -> [PASS][209] +3 similar issues
   [208]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-dg1-16/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-d-hdmi-a-1.html
   [209]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-dg1-13/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-d-hdmi-a-1.html

  * igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-pixel-formats@pipe-b-edp-1:
    - shard-iclb:         [SKIP][210] ([i915#5176]) -> [PASS][211] +1 similar issue
   [210]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb3/igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-pixel-formats@pipe-b-edp-1.html
   [211]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb7/igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-pixel-formats@pipe-b-edp-1.html

  * igt@kms_plane_scaling@planes-upscale-20x20@pipe-d-hdmi-a-1:
    - {shard-dg1}:        [SKIP][212] -> [PASS][213] +4 similar issues
   [212]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-dg1-16/igt@kms_plane_scaling@planes-upscale-20x20@pipe-d-hdmi-a-1.html
   [213]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-dg1-13/igt@kms_plane_scaling@planes-upscale-20x20@pipe-d-hdmi-a-1.html

  * igt@kms_properties@crtc-properties-atomic:
    - {shard-rkl}:        [SKIP][214] ([i915#1849]) -> [PASS][215]
   [214]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@kms_properties@crtc-properties-atomic.html
   [215]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@kms_properties@crtc-properties-atomic.html

  * igt@kms_psr@dpms:
    - {shard-rkl}:        [SKIP][216] ([i915#1072]) -> [PASS][217] +2 similar issues
   [216]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-1/igt@kms_psr@dpms.html
   [217]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@kms_psr@dpms.html

  * igt@kms_psr@psr2_cursor_mmap_gtt:
    - shard-iclb:         [SKIP][218] ([fdo#109441]) -> [PASS][219] +3 similar issues
   [218]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb1/igt@kms_psr@psr2_cursor_mmap_gtt.html
   [219]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_gtt.html

  * igt@kms_universal_plane@cursor-fb-leak-pipe-a:
    - {shard-rkl}:        [SKIP][220] ([i915#1845] / [i915#4070] / [i915#4098]) -> [PASS][221] +1 similar issue
   [220]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-1/igt@kms_universal_plane@cursor-fb-leak-pipe-a.html
   [221]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@kms_universal_plane@cursor-fb-leak-pipe-a.html

  * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
    - {shard-rkl}:        [SKIP][222] ([i915#1845] / [i915#4098]) -> [PASS][223] +27 similar issues
   [222]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html
   [223]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html

  * igt@perf@polling-small-buf:
    - {shard-rkl}:        [FAIL][224] ([i915#1722]) -> [PASS][225]
   [224]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@perf@polling-small-buf.html
   [225]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-6/igt@perf@polling-small-buf.html
    - shard-skl:          [FAIL][226] ([i915#1722]) -> [PASS][227]
   [226]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-skl10/igt@perf@polling-small-buf.html
   [227]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl4/igt@perf@polling-small-buf.html

  * igt@prime_vgem@basic-write:
    - {shard-rkl}:        [SKIP][228] ([fdo#109295] / [i915#3291] / [i915#3708]) -> [PASS][229]
   [228]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-rkl-2/igt@prime_vgem@basic-write.html
   [229]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-rkl-5/igt@prime_vgem@basic-write.html

  
#### Warnings ####

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
    - shard-iclb:         [FAIL][230] ([i915#2852]) -> [FAIL][231] ([i915#2842])
   [230]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb7/igt@gem_exec_fair@basic-none-rrul@rcs0.html
   [231]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb5/igt@gem_exec_fair@basic-none-rrul@rcs0.html

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-kbl:          [INCOMPLETE][232] ([i915#180] / [i915#4939]) -> [FAIL][233] ([i915#4767])
   [232]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@kms_fbcon_fbt@fbc-suspend.html
   [233]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl7/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1:
    - shard-kbl:          [DMESG-WARN][234] ([i915#180]) -> [DMESG-FAIL][235] ([i915#180])
   [234]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1.html
   [235]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl1/igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1.html

  * igt@kms_psr2_sf@cursor-plane-move-continuous-sf:
    - shard-iclb:         [SKIP][236] ([i915#2920]) -> [SKIP][237] ([i915#658])
   [236]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb2/igt@kms_psr2_sf@cursor-plane-move-continuous-sf.html
   [237]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb8/igt@kms_psr2_sf@cursor-plane-move-continuous-sf.html

  * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area:
    - shard-iclb:         [SKIP][238] ([fdo#111068] / [i915#658]) -> [SKIP][239] ([i915#2920]) +1 similar issue
   [238]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb3/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area.html
   [239]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb2/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area.html

  * igt@kms_psr2_su@page_flip-nv12:
    - shard-iclb:         [FAIL][240] ([i915#5939]) -> [SKIP][241] ([fdo#109642] / [fdo#111068] / [i915#658])
   [240]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb2/igt@kms_psr2_su@page_flip-nv12.html
   [241]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb4/igt@kms_psr2_su@page_flip-nv12.html

  * igt@runner@aborted:
    - shard-skl:          ([FAIL][242], [FAIL][243], [FAIL][244], [FAIL][245]) ([i915#2029] / [i915#3002] / [i915#4312] / [i915#5257]) -> ([FAIL][246], [FAIL][247]) ([i915#3002] / [i915#4312] / [i915#5257])
   [242]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-skl10/igt@runner@aborted.html
   [243]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-skl3/igt@runner@aborted.html
   [244]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-skl3/igt@runner@aborted.html
   [245]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-skl7/igt@runner@aborted.html
   [246]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl4/igt@runner@aborted.html
   [247]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl6/igt@runner@aborted.html
    - shard-apl:          ([FAIL][248], [FAIL][249], [FAIL][250], [FAIL][251], [FAIL][252], [FAIL][253]) ([i915#180] / [i915#3002] / [i915#4312] / [i915#5257]) -> ([FAIL][254], [FAIL][255], [FAIL][256], [FAIL][257], [FAIL][258]) ([fdo#109271] / [i915#3002] / [i915#4312] / [i915#5257])
   [248]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl3/igt@runner@aborted.html
   [249]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl3/igt@runner@aborted.html
   [250]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl3/igt@runner@aborted.html
   [251]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl6/igt@runner@aborted.html
   [252]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl8/igt@runner@aborted.html
   [253]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl2/igt@runner@aborted.html
   [254]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl3/igt@runner@aborted.html
   [255]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl3/igt@runner@aborted.html
   [256]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl8/igt@runner@aborted.html
   [257]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl1/igt@runner@aborted.html
   [258]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-apl7/igt@runner@aborted.html
    - shard-kbl:          ([FAIL][259], [FAIL][260], [FAIL][261], [FAIL][262], [FAIL][263], [FAIL][264], [FAIL][265], [FAIL][266], [FAIL][267], [FAIL][268], [FAIL][269], [FAIL][270], [FAIL][271]) ([i915#180] / [i915#3002] / [i915#4312] / [i915#5257] / [i915#92]) -> ([FAIL][272], [FAIL][273], [FAIL][274], [FAIL][275], [FAIL][276], [FAIL][277], [FAIL][278], [FAIL][279], [FAIL][280], [FAIL][281], [FAIL][282], [FAIL][283], [FAIL][284]) ([i915#180] / [i915#3002] / [i915#4312] / [i915#5257])
   [259]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl4/igt@runner@aborted.html
   [260]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@runner@aborted.html
   [261]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@runner@aborted.html
   [262]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl1/igt@runner@aborted.html
   [263]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl6/igt@runner@aborted.html
   [264]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl6/igt@runner@aborted.html
   [265]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@runner@aborted.html
   [266]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl6/igt@runner@aborted.html
   [267]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl6/igt@runner@aborted.html
   [268]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@runner@aborted.html
   [269]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl1/igt@runner@aborted.html
   [270]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl1/igt@runner@aborted.html
   [271]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@runner@aborted.html
   [272]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl1/igt@runner@aborted.html
   [273]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@runner@aborted.html
   [274]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@runner@aborted.html
   [275]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl1/igt@runner@aborted.html
   [276]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl1/igt@runner@aborted.html
   [277]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl4/igt@runner@aborted.html
   [278]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl1/igt@runner@aborted.html
   [279]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl1/igt@runner@aborted.html
   [280]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl7/igt@runner@aborted.html
   [281]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@runner@aborted.html
   [282]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@runner@aborted.html
   [283]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl4/igt@runner@aborted.html
   [284]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@runner@aborted.html

  

### Piglit changes ###

#### Issues hit ####

  * spec@glsl-1.10@execution@built-in-functions@fs-op-add-ivec4-ivec4:
    - pig-skl-6260u:      NOTRUN -> [INCOMPLETE][285] ([i915#6322])
   [285]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/pig-skl-6260u/spec@glsl-1.10@execution@built-in-functions@fs-op-add-ivec4-ivec4.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
  [fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110723]: https://bugs.freedesktop.org/show_bug.cgi?id=110723
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111314]: https://bugs.freedesktop.org/show_bug.cgi?id=111314
  [fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614
  [fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
  [fdo#111656]: https://bugs.freedesktop.org/show_bug.cgi?id=111656
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [fdo#112054]: https://bugs.freedesktop.org/show_bug.cgi?id=112054
  [fdo#112283]: https://bugs.freedesktop.org/show_bug.cgi?id=112283
  [i915#1063]: https://gitlab.freedesktop.org/drm/intel/issues/1063
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1149]: https://gitlab.freedesktop.org/drm/intel/issues/1149
  [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
  [i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319
  [i915#132]: https://gitlab.freedesktop.org/drm/intel/issues/132
  [i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
  [i915#1722]: https://gitlab.freedesktop.org/drm/intel/issues/1722
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1825]: https://gitlab.freedesktop.org/drm/intel/issues/1825
  [i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
  [i915#2410]: https://gitlab.freedesktop.org/drm/intel/issues/2410
  [i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437
  [i915#2521]: https://gitlab.freedesktop.org/drm/intel/issues/2521
  [i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527
  [i915#2530]: https://gitlab.freedesktop.org/drm/intel/issues/2530
  [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
  [i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658
  [i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672
  [i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
  [i915#2849]: https://gitlab.freedesktop.org/drm/intel/issues/2849
  [i915#2852]: https://gitlab.freedesktop.org/drm/intel/issues/2852
  [i915#2856]: https://gitlab.freedesktop.org/drm/intel/issues/2856
  [i915#2920]: https://gitlab.freedesktop.org/drm/intel/issues/2920
  [i915#2994]: https://gitlab.freedesktop.org/drm/intel/issues/2994
  [i915#3002]: https://gitlab.freedesktop.org/drm/intel/issues/3002
  [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
  [i915#3063]: https://gitlab.freedesktop.org/drm/intel/issues/3063
  [i915#3116]: https://gitlab.freedesktop.org/drm/intel/issues/3116
  [i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297
  [i915#3318]: https://gitlab.freedesktop.org/drm/intel/issues/3318
  [i915#3323]: https://gitlab.freedesktop.org/drm/intel/issues/3323
  [i915#3376]: https://gitlab.freedesktop.org/drm/intel/issues/3376
  [i915#3458]: https://gitlab.freedesktop.org/drm/intel/issues/3458
  [i915#3467]: https://gitlab.freedesktop.org/drm/intel/issues/3467
  [i915#3469]: https://gitlab.freedesktop.org/drm/intel/issues/3469
  [i915#3536]: https://gitlab.freedesktop.org/drm/intel/issues/3536
  [i915#3539]: https://gitlab.freedesktop.org/drm/intel/issues/3539
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3558]: https://gitlab.freedesktop.org/drm/intel/issues/3558
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#3638]: https://gitlab.freedesktop.org/drm/intel/issues/3638
  [i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
  [i915#3701]: https://gitlab.freedesktop.org/drm/intel/issues/3701
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#3734]: https://gitlab.freedesktop.org/drm/intel/issues/3734
  [i915#3743]: https://gitlab.freedesktop.org/drm/intel/issues/3743
  [i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#3989]: https://gitlab.freedesktop.org/drm/intel/issues/3989
  [i915#4070]: https://gitlab.freedesktop.org/drm/intel/issues/4070
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4171]: https://gitlab.freedesktop.org/drm/intel/issues/4171
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270
  [i915#4278]: https://gitlab.freedesktop.org/drm/intel/issues/4278
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4369]: https://gitlab.freedesktop.org/drm/intel/issues/4369
  [i915#4525]: https://gitlab.freedesktop.org/drm/intel/issues/4525
  [i915#4538]: https://gitlab.freedesktop.org/drm/intel/issues/4538
  [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4767]: https://gitlab.freedesktop.org/drm/intel/issues/4767
  [i915#4812]: https://gitlab.freedesktop.org/drm/intel/issues/4812
  [i915#4833]: https://gitlab.freedesktop.org/drm/intel/issues/4833
  [i915#4839]: https://gitlab.freedesktop.org/drm/intel/issues/4839
  [i915#4852]: https://gitlab.freedesktop.org/drm/intel/issues/4852
  [i915#4853]: https://gitlab.freedesktop.org/drm/intel/issues/4853
  [i915#4883]: https://gitlab.freedesktop.org/drm/intel/issues/4883
  [i915#4893]: https://gitlab.freedesktop.org/drm/intel/issues/4893
  [i915#4904]: https://gitlab.freedesktop.org/drm/intel/issues/4904
  [i915#4911]: https://gitlab.freedesktop.org/drm/intel/issues/4911
  [i915#4936]: https://gitlab.freedesktop.org/drm/intel/issues/4936
  [i915#4939]: https://gitlab.freedesktop.org/drm/intel/issues/4939
  [i915#4991]: https://gitlab.freedesktop.org/drm/intel/issues/4991
  [i915#5090]: https://gitlab.freedesktop.org/drm/intel/issues/5090
  [i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
  [i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
  [i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257
  [i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286
  [i915#5287]: https://gitlab.freedesktop.org/drm/intel/issues/5287
  [i915#5288]: https://gitlab.freedesktop.org/drm/intel/issues/5288
  [i915#5289]: https://gitlab.freedesktop.org/drm/intel/issues/5289
  [i915#5325]: https://gitlab.freedesktop.org/drm/intel/issues/5325
  [i915#5327]: https://gitlab.freedesktop.org/drm/intel/issues/5327
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [i915#5439]: https://gitlab.freedesktop.org/drm/intel/issues/5439
  [i915#5563]: https://gitlab.freedesktop.org/drm/intel/issues/5563
  [i915#5566]: https://gitlab.freedesktop.org/drm/intel/issues/5566
  [i915#5721]: https://gitlab.freedesktop.org/drm/intel/issues/5721
  [i915#5776]: https://gitlab.freedesktop.org/drm/intel/issues/5776
  [i915#5784]: https://gitlab.freedesktop.org/drm/intel/issues/5784
  [i915#5903]: https://gitlab.freedesktop.org/drm/intel/issues/5903
  [i915#5939]: https://gitlab.freedesktop.org/drm/intel/issues/5939
  [i915#5971]: https://gitlab.freedesktop.org/drm/intel/issues/5971
  [i915#6095]: https://gitlab.freedesktop.org/drm/intel/issues/6095
  [i915#6140]: https://gitlab.freedesktop.org/drm/intel/issues/6140
  [i915#6227]: https://gitlab.freedesktop.org/drm/intel/issues/6227
  [i915#6248]: https://gitlab.freedesktop.org/drm/intel/issues/6248
  [i915#6252]: https://gitlab.freedesktop.org/drm/intel/issues/6252
  [i915#6268]: https://gitlab.freedesktop.org/drm/intel/issues/6268
  [i915#6310]: https://gitlab.freedesktop.org/drm/intel/issues/6310
  [i915#6322]: https://gitlab.freedesktop.org/drm/intel/issues/6322
  [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
  [i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716
  [i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92


Build changes
-------------

  * Linux: CI_DRM_11835 -> Patchwork_105790v2

  CI-20190529: 20190529
  CI_DRM_11835: 04a306d4367231c6a86c1d415eb2596aaf7aca5f @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6553: 3cf110f8dcd1f4f02cf84339664b413abdaebf7d @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_105790v2: 04a306d4367231c6a86c1d415eb2596aaf7aca5f @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/index.html

[-- Attachment #2: Type: text/html, Size: 79374 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-07-01  8:37   ` Tvrtko Ursulin
@ 2022-07-01 14:54     ` Summers, Stuart
  2022-07-04  8:31       ` Tvrtko Ursulin
  2022-07-01 18:09     ` Umesh Nerlige Ramappa
  1 sibling, 1 reply; 21+ messages in thread
From: Summers, Stuart @ 2022-07-01 14:54 UTC (permalink / raw)
  To: Nerlige Ramappa, Umesh, tvrtko.ursulin; +Cc: intel-gfx

On Fri, 2022-07-01 at 09:37 +0100, Tvrtko Ursulin wrote:
> On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
> > On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart Summers wrote:
> > > In the driver teardown, we are unregistering the gt prior
> > > to unregistering the PMU. This means there is a small window
> > > of time in which the application can request metrics from the
> > > PMU, some of which are calling into the uapi engines list,
> > > while the engines are not available. In this case we can
> > > see null pointer dereferences.
> > > 
> > > Fix this ordering in both the driver load and unload sequences.
> > > 
> > > Additionally add a check for engine presence to prevent this
> > > NPD in the event this ordering is accidentally reversed. Print
> > > a debug message indicating when they aren't available.
> > > 
> > > v1: Actually address the driver load/unload ordering issue
> > > 
> > > Signed-off-by: Stuart Summers <stuart.summers@intel.com>
> > > ---
> > 
> > I thought this is likely happening because intel_gpu_top is running
> > in 
> > the background when i915 is unloaded. I tried a quick repro, I
> > don't see 
> > the unload succeed ("fatal module in use", not sure if this was a 
> > partial unload), but when I try to kill intel_gpu_top, I get an
> > NPD. 
> > This is in the event disable path - i915_pmu_event_stop -> 
> > i915_pmu_disable.
> 
> So i915 failed to unload (as expected - with perf events open we
> elevate 
> the module ref count via i915_pmu_event_init -> drm_dev_get), then
> you 
> quit intel_gpu_top and get NPD? On the engine lookup? With the 
> re-ordered init/fini sequence as from this patch?
> 
> With elevated module count there shouldn't be any unloading happening
> so 
> I am intrigued.
> 
> > It's likely that you are seeing a different path (unload) leading
> > to the 
> > same issue.
> > 
> > I think in i915_pmu_disable/disable should be aware of event-
> > >hw.state 
> > and or pmu->closed states before accessing the event. Maybe like,
> > 
> > if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event))
> > {
> > 
> > @Tvrtko, wondering if this case is tested by igt@perf
> > _pmu@module-unload. 
> 
> A bit yes. From what Stuart wrote it seems the test would need to be 
> extended to cover the case where PMU is getting opened while module 
> unload is in progress.
> 
> But the NPD you saw is for the moment confusing so I don't know what
> is 
> happening.
> 
> > I am not clear if we should use event->hw.state or pmu->closed here
> > and 
> > if/how they are related. IMO, for this issue, the engine check is
> > good 
> > enough too, so we don't really need the pmu state checks. 
> > Thoughts?
> 
> Engine check at the moment feels like papering.
> 
> Indeed as you say I think the pmu->closed might be the solution.
> Perhaps 
> the race is as mentioned above. PMU open happening in parallel to
> unload..
> 
> If the sequence of events userspace triggers is:
> 
>    i915_pmu_event_init
>    i915_pmu_event_start
>    i915_pmu_enable
>    i915_pmu_event_read
> 
> I guess pmu->closed can get set halfway in i915_pmu_event_init. What 
> would be the effect of that.. We'd try to get a module reference
> while 
> in the process of unloading. Which is probably very bad.. So possibly
> a 
> final check on pmu->close is needed there. Ho hum.. can it be made
> safe 
> is the question.
> 
> It doesn't explain the NPD on Ctrl-C though.. intel_gpu_top keeps
> the 
> evens open all the time. So I think more info needed, for me at
> least.

So one thing here is this doesn't have to do with module unload, but
module unbind specifically (while perf is open). I don't know if the
NPD from Umesh is the same as what we're seeing here. I'd really like
to separate these unless you know for sure that's related. Also it
would be interesting to know if this patch fixes your issue as well.

I still think the re-ordering in i915_driver.c should be enough and we
shouldn't need to check pmu->closed. The unregister should be enough to
ensure the perf tools are notified that new events aren't allowed, and
at that time the engine structures are still intact. And even if for
some reason the perf code still calls in to our function pointers, we
have these engine checks as a failsafe.

I'm by the way uploading one more version here with a drm_WARN_ONCE
instead of the debug print.

Thanks,
Stuart

> 
> Regards,
> 
> Tvrtko
> 
> > Regards,
> > Umesh
> > 
> > > drivers/gpu/drm/i915/i915_driver.c | 11 ++---
> > > drivers/gpu/drm/i915/i915_pmu.c    | 72 +++++++++++++++++------
> > > -------
> > > 2 files changed, 48 insertions(+), 35 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_driver.c 
> > > b/drivers/gpu/drm/i915/i915_driver.c
> > > index deb8a8b76965..ee4dcb85d206 100644
> > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > @@ -717,7 +717,6 @@ static void i915_driver_register(struct 
> > > drm_i915_private *dev_priv)
> > >     struct drm_device *dev = &dev_priv->drm;
> > > 
> > >     i915_gem_driver_register(dev_priv);
> > > -    i915_pmu_register(dev_priv);
> > > 
> > >     intel_vgpu_register(dev_priv);
> > > 
> > > @@ -731,11 +730,12 @@ static void i915_driver_register(struct 
> > > drm_i915_private *dev_priv)
> > >     i915_debugfs_register(dev_priv);
> > >     i915_setup_sysfs(dev_priv);
> > > 
> > > +    intel_gt_driver_register(to_gt(dev_priv));
> > > +
> > >     /* Depends on sysfs having been initialized */
> > > +    i915_pmu_register(dev_priv);
> > >     i915_perf_register(dev_priv);
> > > 
> > > -    intel_gt_driver_register(to_gt(dev_priv));
> > > -
> > >     intel_display_driver_register(dev_priv);
> > > 
> > >     intel_power_domains_enable(dev_priv);
> > > @@ -762,11 +762,12 @@ static void i915_driver_unregister(struct 
> > > drm_i915_private *dev_priv)
> > > 
> > >     intel_display_driver_unregister(dev_priv);
> > > 
> > > -    intel_gt_driver_unregister(to_gt(dev_priv));
> > > -
> > >     i915_perf_unregister(dev_priv);
> > > +    /* GT should be available until PMU is gone */
> > >     i915_pmu_unregister(dev_priv);
> > > 
> > > +    intel_gt_driver_unregister(to_gt(dev_priv));
> > > +
> > >     i915_teardown_sysfs(dev_priv);
> > >     drm_dev_unplug(&dev_priv->drm);
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
> > > b/drivers/gpu/drm/i915/i915_pmu.c
> > > index 958b37123bf1..796a1d8e36f2 100644
> > > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > > @@ -670,21 +670,28 @@ static void i915_pmu_enable(struct
> > > perf_event 
> > > *event)
> > >     if (is_engine_event(event)) {
> > >         u8 sample = engine_event_sample(event);
> > >         struct intel_engine_cs *engine;
> > > -
> > > -        engine = intel_engine_lookup_user(i915,
> > > -                          engine_event_class(event),
> > > -                          engine_event_instance(event));
> > > -
> > > -        BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
> > > -                 I915_ENGINE_SAMPLE_COUNT);
> > > -        BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
> > > -                 I915_ENGINE_SAMPLE_COUNT);
> > > -        GEM_BUG_ON(sample >= ARRAY_SIZE(engine-
> > > >pmu.enable_count));
> > > -        GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
> > > -        GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
> > > -
> > > -        engine->pmu.enable |= BIT(sample);
> > > -        engine->pmu.enable_count[sample]++;
> > > +        u8 class = engine_event_class(event);
> > > +        u8 instance = engine_event_instance(event);
> > > +
> > > +        engine = intel_engine_lookup_user(i915, class,
> > > instance);
> > > +        if (engine) {
> > > +            BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
> > > +                     I915_ENGINE_SAMPLE_COUNT);
> > > +            BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
> > > +                     I915_ENGINE_SAMPLE_COUNT);
> > > +            GEM_BUG_ON(sample >=
> > > +                   ARRAY_SIZE(engine->pmu.enable_count));
> > > +            GEM_BUG_ON(sample >=
> > > +                   ARRAY_SIZE(engine->pmu.sample));
> > > +            GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
> > > +
> > > +            engine->pmu.enable |= BIT(sample);
> > > +            engine->pmu.enable_count[sample]++;
> > > +        } else {
> > > +            drm_dbg(&i915->drm,
> > > +                "Invalid engine event: { class:%d, inst:%d }\n",
> > > +                class, instance);
> > > +        }
> > >     }
> > > 
> > >     spin_unlock_irqrestore(&pmu->lock, flags);
> > > @@ -714,21 +721,26 @@ static void i915_pmu_disable(struct
> > > perf_event 
> > > *event)
> > >     if (is_engine_event(event)) {
> > >         u8 sample = engine_event_sample(event);
> > >         struct intel_engine_cs *engine;
> > > -
> > > -        engine = intel_engine_lookup_user(i915,
> > > -                          engine_event_class(event),
> > > -                          engine_event_instance(event));
> > > -
> > > -        GEM_BUG_ON(sample >= ARRAY_SIZE(engine-
> > > >pmu.enable_count));
> > > -        GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
> > > -        GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
> > > -
> > > -        /*
> > > -         * Decrement the reference count and clear the enabled
> > > -         * bitmask when the last listener on an event goes away.
> > > -         */
> > > -        if (--engine->pmu.enable_count[sample] == 0)
> > > -            engine->pmu.enable &= ~BIT(sample);
> > > +        u8 class = engine_event_class(event);
> > > +        u8 instance = engine_event_instance(event);
> > > +
> > > +        engine = intel_engine_lookup_user(i915, class,
> > > instance);
> > > +        if (engine) {
> > > +            GEM_BUG_ON(sample >= ARRAY_SIZE(engine-
> > > >pmu.enable_count));
> > > +            GEM_BUG_ON(sample >= ARRAY_SIZE(engine-
> > > >pmu.sample));
> > > +            GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
> > > +
> > > +            /*
> > > +             * Decrement the reference count and clear the
> > > enabled
> > > +             * bitmask when the last listener on an event goes
> > > away.
> > > +             */
> > > +            if (--engine->pmu.enable_count[sample] == 0)
> > > +                engine->pmu.enable &= ~BIT(sample);
> > > +        } else {
> > > +            drm_dbg(&i915->drm,
> > > +                "Invalid engine event: { class:%d, inst:%d }\n",
> > > +                class, instance);
> > > +        }
> > >     }
> > > 
> > >     GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));
> > > -- 
> > > 2.25.1
> > > 

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-07-01  8:37   ` Tvrtko Ursulin
  2022-07-01 14:54     ` Summers, Stuart
@ 2022-07-01 18:09     ` Umesh Nerlige Ramappa
  1 sibling, 0 replies; 21+ messages in thread
From: Umesh Nerlige Ramappa @ 2022-07-01 18:09 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

On Fri, Jul 01, 2022 at 09:37:20AM +0100, Tvrtko Ursulin wrote:
>
>On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
>>On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart Summers wrote:
>>>In the driver teardown, we are unregistering the gt prior
>>>to unregistering the PMU. This means there is a small window
>>>of time in which the application can request metrics from the
>>>PMU, some of which are calling into the uapi engines list,
>>>while the engines are not available. In this case we can
>>>see null pointer dereferences.
>>>
>>>Fix this ordering in both the driver load and unload sequences.
>>>
>>>Additionally add a check for engine presence to prevent this
>>>NPD in the event this ordering is accidentally reversed. Print
>>>a debug message indicating when they aren't available.
>>>
>>>v1: Actually address the driver load/unload ordering issue
>>>
>>>Signed-off-by: Stuart Summers <stuart.summers@intel.com>
>>>---
>>
>>I thought this is likely happening because intel_gpu_top is running 
>>in the background when i915 is unloaded. I tried a quick repro, I 
>>don't see the unload succeed ("fatal module in use", not sure if 
>>this was a partial unload), but when I try to kill intel_gpu_top, I 
>>get an NPD. This is in the event disable path - i915_pmu_event_stop 
>>-> i915_pmu_disable.
>
>So i915 failed to unload (as expected - with perf events open we 
>elevate the module ref count via i915_pmu_event_init -> drm_dev_get), 
>then you quit intel_gpu_top and get NPD?

I was just trying to point out an instance of the failure that I saw 
when running this execution sequence. This is without any of Stuart's 
changes.

> On the engine lookup?

Don't know if it is specifically engine lookup, but it's in the path of 
i915_pmu_event_stop which executes on killing intel_gpu_top.

> With the re-ordered init/fini sequence as from this patch?
No, without any changes from this thread.

>
>With elevated module count there shouldn't be any unloading happening 
>so I am intrigued.
>
>>It's likely that you are seeing a different path (unload) leading to 
>>the same issue.
>>
>>I think in i915_pmu_disable/disable should be aware of 
>>event->hw.state and or pmu->closed states before accessing the 
>>event. Maybe like,
>>
>>if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event)) {
>>
>>@Tvrtko, wondering if this case is tested by 
>>igt@perf_pmu@module-unload.
>
>A bit yes. From what Stuart wrote it seems the test would need to be 
>extended to cover the case where PMU is getting opened while module 
>unload is in progress.
>
>But the NPD you saw is for the moment confusing so I don't know what 
>is happening.

I guess it's a separate issue. I can check if Stuart's patches resolve 
it and if not, will create a bug.

Regards,
Umesh

>
>>I am not clear if we should use event->hw.state or pmu->closed here 
>>and if/how they are related. IMO, for this issue, the engine check 
>>is good enough too, so we don't really need the pmu state checks.  
>>Thoughts?
>
>Engine check at the moment feels like papering.
>
>Indeed as you say I think the pmu->closed might be the solution. 
>Perhaps the race is as mentioned above. PMU open happening in parallel 
>to unload..
>
>If the sequence of events userspace triggers is:
>
>  i915_pmu_event_init
>  i915_pmu_event_start
>  i915_pmu_enable
>  i915_pmu_event_read
>
>I guess pmu->closed can get set halfway in i915_pmu_event_init. What 
>would be the effect of that.. We'd try to get a module reference while 
>in the process of unloading. Which is probably very bad.. So possibly 
>a final check on pmu->close is needed there. Ho hum.. can it be made 
>safe is the question.
>
>It doesn't explain the NPD on Ctrl-C though.. intel_gpu_top keeps the 
>evens open all the time. So I think more info needed, for me at least.
>
>Regards,
>
>Tvrtko
>
>>
>>Regards,
>>Umesh
>>
>>>drivers/gpu/drm/i915/i915_driver.c | 11 ++---
>>>drivers/gpu/drm/i915/i915_pmu.c    | 72 +++++++++++++++++-------------
>>>2 files changed, 48 insertions(+), 35 deletions(-)
>>>
>>>diff --git a/drivers/gpu/drm/i915/i915_driver.c 
>>>b/drivers/gpu/drm/i915/i915_driver.c
>>>index deb8a8b76965..ee4dcb85d206 100644
>>>--- a/drivers/gpu/drm/i915/i915_driver.c
>>>+++ b/drivers/gpu/drm/i915/i915_driver.c
>>>@@ -717,7 +717,6 @@ static void i915_driver_register(struct 
>>>drm_i915_private *dev_priv)
>>>    struct drm_device *dev = &dev_priv->drm;
>>>
>>>    i915_gem_driver_register(dev_priv);
>>>-    i915_pmu_register(dev_priv);
>>>
>>>    intel_vgpu_register(dev_priv);
>>>
>>>@@ -731,11 +730,12 @@ static void i915_driver_register(struct 
>>>drm_i915_private *dev_priv)
>>>    i915_debugfs_register(dev_priv);
>>>    i915_setup_sysfs(dev_priv);
>>>
>>>+    intel_gt_driver_register(to_gt(dev_priv));
>>>+
>>>    /* Depends on sysfs having been initialized */
>>>+    i915_pmu_register(dev_priv);
>>>    i915_perf_register(dev_priv);
>>>
>>>-    intel_gt_driver_register(to_gt(dev_priv));
>>>-
>>>    intel_display_driver_register(dev_priv);
>>>
>>>    intel_power_domains_enable(dev_priv);
>>>@@ -762,11 +762,12 @@ static void i915_driver_unregister(struct 
>>>drm_i915_private *dev_priv)
>>>
>>>    intel_display_driver_unregister(dev_priv);
>>>
>>>-    intel_gt_driver_unregister(to_gt(dev_priv));
>>>-
>>>    i915_perf_unregister(dev_priv);
>>>+    /* GT should be available until PMU is gone */
>>>    i915_pmu_unregister(dev_priv);
>>>
>>>+    intel_gt_driver_unregister(to_gt(dev_priv));
>>>+
>>>    i915_teardown_sysfs(dev_priv);
>>>    drm_dev_unplug(&dev_priv->drm);
>>>
>>>diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
>>>b/drivers/gpu/drm/i915/i915_pmu.c
>>>index 958b37123bf1..796a1d8e36f2 100644
>>>--- a/drivers/gpu/drm/i915/i915_pmu.c
>>>+++ b/drivers/gpu/drm/i915/i915_pmu.c
>>>@@ -670,21 +670,28 @@ static void i915_pmu_enable(struct 
>>>perf_event *event)
>>>    if (is_engine_event(event)) {
>>>        u8 sample = engine_event_sample(event);
>>>        struct intel_engine_cs *engine;
>>>-
>>>-        engine = intel_engine_lookup_user(i915,
>>>-                          engine_event_class(event),
>>>-                          engine_event_instance(event));
>>>-
>>>-        BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
>>>-                 I915_ENGINE_SAMPLE_COUNT);
>>>-        BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
>>>-                 I915_ENGINE_SAMPLE_COUNT);
>>>-        GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
>>>-        GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
>>>-        GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
>>>-
>>>-        engine->pmu.enable |= BIT(sample);
>>>-        engine->pmu.enable_count[sample]++;
>>>+        u8 class = engine_event_class(event);
>>>+        u8 instance = engine_event_instance(event);
>>>+
>>>+        engine = intel_engine_lookup_user(i915, class, instance);
>>>+        if (engine) {
>>>+            BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
>>>+                     I915_ENGINE_SAMPLE_COUNT);
>>>+            BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
>>>+                     I915_ENGINE_SAMPLE_COUNT);
>>>+            GEM_BUG_ON(sample >=
>>>+                   ARRAY_SIZE(engine->pmu.enable_count));
>>>+            GEM_BUG_ON(sample >=
>>>+                   ARRAY_SIZE(engine->pmu.sample));
>>>+            GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
>>>+
>>>+            engine->pmu.enable |= BIT(sample);
>>>+            engine->pmu.enable_count[sample]++;
>>>+        } else {
>>>+            drm_dbg(&i915->drm,
>>>+                "Invalid engine event: { class:%d, inst:%d }\n",
>>>+                class, instance);
>>>+        }
>>>    }
>>>
>>>    spin_unlock_irqrestore(&pmu->lock, flags);
>>>@@ -714,21 +721,26 @@ static void i915_pmu_disable(struct 
>>>perf_event *event)
>>>    if (is_engine_event(event)) {
>>>        u8 sample = engine_event_sample(event);
>>>        struct intel_engine_cs *engine;
>>>-
>>>-        engine = intel_engine_lookup_user(i915,
>>>-                          engine_event_class(event),
>>>-                          engine_event_instance(event));
>>>-
>>>-        GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
>>>-        GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
>>>-        GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
>>>-
>>>-        /*
>>>-         * Decrement the reference count and clear the enabled
>>>-         * bitmask when the last listener on an event goes away.
>>>-         */
>>>-        if (--engine->pmu.enable_count[sample] == 0)
>>>-            engine->pmu.enable &= ~BIT(sample);
>>>+        u8 class = engine_event_class(event);
>>>+        u8 instance = engine_event_instance(event);
>>>+
>>>+        engine = intel_engine_lookup_user(i915, class, instance);
>>>+        if (engine) {
>>>+            GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
>>>+            GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
>>>+            GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
>>>+
>>>+            /*
>>>+             * Decrement the reference count and clear the enabled
>>>+             * bitmask when the last listener on an event goes away.
>>>+             */
>>>+            if (--engine->pmu.enable_count[sample] == 0)
>>>+                engine->pmu.enable &= ~BIT(sample);
>>>+        } else {
>>>+            drm_dbg(&i915->drm,
>>>+                "Invalid engine event: { class:%d, inst:%d }\n",
>>>+                class, instance);
>>>+        }
>>>    }
>>>
>>>    GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));
>>>-- 
>>>2.25.1
>>>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-07-01 14:54     ` Summers, Stuart
@ 2022-07-04  8:31       ` Tvrtko Ursulin
  2022-07-12 21:03         ` Umesh Nerlige Ramappa
  0 siblings, 1 reply; 21+ messages in thread
From: Tvrtko Ursulin @ 2022-07-04  8:31 UTC (permalink / raw)
  To: Summers, Stuart, Nerlige Ramappa, Umesh; +Cc: intel-gfx


On 01/07/2022 15:54, Summers, Stuart wrote:
> On Fri, 2022-07-01 at 09:37 +0100, Tvrtko Ursulin wrote:
>> On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
>>> On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart Summers wrote:
>>>> In the driver teardown, we are unregistering the gt prior
>>>> to unregistering the PMU. This means there is a small window
>>>> of time in which the application can request metrics from the
>>>> PMU, some of which are calling into the uapi engines list,
>>>> while the engines are not available. In this case we can
>>>> see null pointer dereferences.
>>>>
>>>> Fix this ordering in both the driver load and unload sequences.
>>>>
>>>> Additionally add a check for engine presence to prevent this
>>>> NPD in the event this ordering is accidentally reversed. Print
>>>> a debug message indicating when they aren't available.
>>>>
>>>> v1: Actually address the driver load/unload ordering issue
>>>>
>>>> Signed-off-by: Stuart Summers <stuart.summers@intel.com>
>>>> ---
>>>
>>> I thought this is likely happening because intel_gpu_top is running
>>> in
>>> the background when i915 is unloaded. I tried a quick repro, I
>>> don't see
>>> the unload succeed ("fatal module in use", not sure if this was a
>>> partial unload), but when I try to kill intel_gpu_top, I get an
>>> NPD.
>>> This is in the event disable path - i915_pmu_event_stop ->
>>> i915_pmu_disable.
>>
>> So i915 failed to unload (as expected - with perf events open we
>> elevate
>> the module ref count via i915_pmu_event_init -> drm_dev_get), then
>> you
>> quit intel_gpu_top and get NPD? On the engine lookup? With the
>> re-ordered init/fini sequence as from this patch?
>>
>> With elevated module count there shouldn't be any unloading happening
>> so
>> I am intrigued.
>>
>>> It's likely that you are seeing a different path (unload) leading
>>> to the
>>> same issue.
>>>
>>> I think in i915_pmu_disable/disable should be aware of event-
>>>> hw.state
>>> and or pmu->closed states before accessing the event. Maybe like,
>>>
>>> if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event))
>>> {
>>>
>>> @Tvrtko, wondering if this case is tested by igt@perf
>>> _pmu@module-unload.
>>
>> A bit yes. From what Stuart wrote it seems the test would need to be
>> extended to cover the case where PMU is getting opened while module
>> unload is in progress.
>>
>> But the NPD you saw is for the moment confusing so I don't know what
>> is
>> happening.
>>
>>> I am not clear if we should use event->hw.state or pmu->closed here
>>> and
>>> if/how they are related. IMO, for this issue, the engine check is
>>> good
>>> enough too, so we don't really need the pmu state checks.
>>> Thoughts?
>>
>> Engine check at the moment feels like papering.
>>
>> Indeed as you say I think the pmu->closed might be the solution.
>> Perhaps
>> the race is as mentioned above. PMU open happening in parallel to
>> unload..
>>
>> If the sequence of events userspace triggers is:
>>
>>     i915_pmu_event_init
>>     i915_pmu_event_start
>>     i915_pmu_enable
>>     i915_pmu_event_read
>>
>> I guess pmu->closed can get set halfway in i915_pmu_event_init. What
>> would be the effect of that.. We'd try to get a module reference
>> while
>> in the process of unloading. Which is probably very bad.. So possibly
>> a
>> final check on pmu->close is needed there. Ho hum.. can it be made
>> safe
>> is the question.
>>
>> It doesn't explain the NPD on Ctrl-C though.. intel_gpu_top keeps
>> the
>> evens open all the time. So I think more info needed, for me at
>> least.
> 
> So one thing here is this doesn't have to do with module unload, but
> module unbind specifically (while perf is open). I don't know if the
> NPD from Umesh is the same as what we're seeing here. I'd really like
> to separate these unless you know for sure that's related. Also it
> would be interesting to know if this patch fixes your issue as well.
> 
> I still think the re-ordering in i915_driver.c should be enough and we
> shouldn't need to check pmu->closed. The unregister should be enough to
> ensure the perf tools are notified that new events aren't allowed, and
> at that time the engine structures are still intact. And even if for
> some reason the perf code still calls in to our function pointers, we
> have these engine checks as a failsafe.
> 
> I'm by the way uploading one more version here with a drm_WARN_ONCE
> instead of the debug print.

Problem is I am not a fan of papering so lets get to the bottom of the 
issue first. (In the meantime simple patch to re-order driver fini is 
okay since that seems obvious enough, I tnink.)

We need to see call traces from any oopses and try to extend perf_pmu to 
catch them. And we need to understand the problem, if it is a real 
problem, which I laid out last week about race between module unload and 
elevating the module use count from our perf event init.

Without understanding the details of possible failure mode flows we 
don't know how much the papering with engine checks solves and how much 
it leaves broken.

If you guys are too busy to tackle that I'll put it onto myself, but 
help would certainly be appreciated.

Regards,

Tvrtko

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-07-04  8:31       ` Tvrtko Ursulin
@ 2022-07-12 21:03         ` Umesh Nerlige Ramappa
  2022-07-19  9:00           ` Tvrtko Ursulin
  0 siblings, 1 reply; 21+ messages in thread
From: Umesh Nerlige Ramappa @ 2022-07-12 21:03 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

On Mon, Jul 04, 2022 at 09:31:55AM +0100, Tvrtko Ursulin wrote:
>
>On 01/07/2022 15:54, Summers, Stuart wrote:
>>On Fri, 2022-07-01 at 09:37 +0100, Tvrtko Ursulin wrote:
>>>On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
>>>>On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart Summers wrote:
>>>>>In the driver teardown, we are unregistering the gt prior
>>>>>to unregistering the PMU. This means there is a small window
>>>>>of time in which the application can request metrics from the
>>>>>PMU, some of which are calling into the uapi engines list,
>>>>>while the engines are not available. In this case we can
>>>>>see null pointer dereferences.
>>>>>
>>>>>Fix this ordering in both the driver load and unload sequences.
>>>>>
>>>>>Additionally add a check for engine presence to prevent this
>>>>>NPD in the event this ordering is accidentally reversed. Print
>>>>>a debug message indicating when they aren't available.
>>>>>
>>>>>v1: Actually address the driver load/unload ordering issue
>>>>>
>>>>>Signed-off-by: Stuart Summers <stuart.summers@intel.com>
>>>>>---
>>>>
>>>>I thought this is likely happening because intel_gpu_top is running
>>>>in
>>>>the background when i915 is unloaded. I tried a quick repro, I
>>>>don't see
>>>>the unload succeed ("fatal module in use", not sure if this was a
>>>>partial unload), but when I try to kill intel_gpu_top, I get an
>>>>NPD.
>>>>This is in the event disable path - i915_pmu_event_stop ->
>>>>i915_pmu_disable.
>>>
>>>So i915 failed to unload (as expected - with perf events open we
>>>elevate
>>>the module ref count via i915_pmu_event_init -> drm_dev_get), then
>>>you
>>>quit intel_gpu_top and get NPD? On the engine lookup? With the
>>>re-ordered init/fini sequence as from this patch?
>>>
>>>With elevated module count there shouldn't be any unloading happening
>>>so
>>>I am intrigued.
>>>
>>>>It's likely that you are seeing a different path (unload) leading
>>>>to the
>>>>same issue.
>>>>
>>>>I think in i915_pmu_disable/disable should be aware of event-
>>>>>hw.state
>>>>and or pmu->closed states before accessing the event. Maybe like,
>>>>
>>>>if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event))
>>>>{
>>>>
>>>>@Tvrtko, wondering if this case is tested by igt@perf
>>>>_pmu@module-unload.
>>>
>>>A bit yes. From what Stuart wrote it seems the test would need to be
>>>extended to cover the case where PMU is getting opened while module
>>>unload is in progress.
>>>
>>>But the NPD you saw is for the moment confusing so I don't know what
>>>is
>>>happening.
>>>
>>>>I am not clear if we should use event->hw.state or pmu->closed here
>>>>and
>>>>if/how they are related. IMO, for this issue, the engine check is
>>>>good
>>>>enough too, so we don't really need the pmu state checks.
>>>>Thoughts?
>>>
>>>Engine check at the moment feels like papering.
>>>
>>>Indeed as you say I think the pmu->closed might be the solution.
>>>Perhaps
>>>the race is as mentioned above. PMU open happening in parallel to
>>>unload..
>>>
>>>If the sequence of events userspace triggers is:
>>>
>>>    i915_pmu_event_init
>>>    i915_pmu_event_start
>>>    i915_pmu_enable
>>>    i915_pmu_event_read
>>>
>>>I guess pmu->closed can get set halfway in i915_pmu_event_init. What
>>>would be the effect of that.. We'd try to get a module reference
>>>while
>>>in the process of unloading. Which is probably very bad.. So possibly
>>>a
>>>final check on pmu->close is needed there. Ho hum.. can it be made
>>>safe
>>>is the question.
>>>
>>>It doesn't explain the NPD on Ctrl-C though.. intel_gpu_top keeps
>>>the
>>>evens open all the time. So I think more info needed, for me at
>>>least.
>>
>>So one thing here is this doesn't have to do with module unload, but
>>module unbind specifically (while perf is open). I don't know if the
>>NPD from Umesh is the same as what we're seeing here. I'd really like
>>to separate these unless you know for sure that's related. Also it
>>would be interesting to know if this patch fixes your issue as well.
>>
>>I still think the re-ordering in i915_driver.c should be enough and we
>>shouldn't need to check pmu->closed. The unregister should be enough to
>>ensure the perf tools are notified that new events aren't allowed, and
>>at that time the engine structures are still intact. And even if for
>>some reason the perf code still calls in to our function pointers, we
>>have these engine checks as a failsafe.
>>
>>I'm by the way uploading one more version here with a drm_WARN_ONCE
>>instead of the debug print.
>
>Problem is I am not a fan of papering so lets get to the bottom of the 
>issue first. (In the meantime simple patch to re-order driver fini is 
>okay since that seems obvious enough, I tnink.)
>
>We need to see call traces from any oopses and try to extend perf_pmu 
>to catch them. And we need to understand the problem, if it is a real 
>problem, which I laid out last week about race between module unload 
>and elevating the module use count from our perf event init.
>
>Without understanding the details of possible failure mode flows we 
>don't know how much the papering with engine checks solves and how 
>much it leaves broken.
>
>If you guys are too busy to tackle that I'll put it onto myself, but 
>help would certainly be appreciated.

Looks like Stuart/Chris are pointing towards the unbind as an issue.

I ran this sequence and only the modprobe showed an error (FATAL: ...  
still in use). What happens with the unbind. Should pmu also handle the 
unbind somehow?

- run intel_gpu_top
- unbind
- modprobe -r i915
- kill intel_gpu_top.

Thanks,
Umesh

>
>Regards,
>
>Tvrtko

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-07-12 21:03         ` Umesh Nerlige Ramappa
@ 2022-07-19  9:00           ` Tvrtko Ursulin
  2022-07-20  0:22             ` Umesh Nerlige Ramappa
  0 siblings, 1 reply; 21+ messages in thread
From: Tvrtko Ursulin @ 2022-07-19  9:00 UTC (permalink / raw)
  To: Umesh Nerlige Ramappa; +Cc: intel-gfx


On 12/07/2022 22:03, Umesh Nerlige Ramappa wrote:
> On Mon, Jul 04, 2022 at 09:31:55AM +0100, Tvrtko Ursulin wrote:
>>
>> On 01/07/2022 15:54, Summers, Stuart wrote:
>>> On Fri, 2022-07-01 at 09:37 +0100, Tvrtko Ursulin wrote:
>>>> On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
>>>>> On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart Summers wrote:
>>>>>> In the driver teardown, we are unregistering the gt prior
>>>>>> to unregistering the PMU. This means there is a small window
>>>>>> of time in which the application can request metrics from the
>>>>>> PMU, some of which are calling into the uapi engines list,
>>>>>> while the engines are not available. In this case we can
>>>>>> see null pointer dereferences.
>>>>>>
>>>>>> Fix this ordering in both the driver load and unload sequences.
>>>>>>
>>>>>> Additionally add a check for engine presence to prevent this
>>>>>> NPD in the event this ordering is accidentally reversed. Print
>>>>>> a debug message indicating when they aren't available.
>>>>>>
>>>>>> v1: Actually address the driver load/unload ordering issue
>>>>>>
>>>>>> Signed-off-by: Stuart Summers <stuart.summers@intel.com>
>>>>>> ---
>>>>>
>>>>> I thought this is likely happening because intel_gpu_top is running
>>>>> in
>>>>> the background when i915 is unloaded. I tried a quick repro, I
>>>>> don't see
>>>>> the unload succeed ("fatal module in use", not sure if this was a
>>>>> partial unload), but when I try to kill intel_gpu_top, I get an
>>>>> NPD.
>>>>> This is in the event disable path - i915_pmu_event_stop ->
>>>>> i915_pmu_disable.
>>>>
>>>> So i915 failed to unload (as expected - with perf events open we
>>>> elevate
>>>> the module ref count via i915_pmu_event_init -> drm_dev_get), then
>>>> you
>>>> quit intel_gpu_top and get NPD? On the engine lookup? With the
>>>> re-ordered init/fini sequence as from this patch?
>>>>
>>>> With elevated module count there shouldn't be any unloading happening
>>>> so
>>>> I am intrigued.
>>>>
>>>>> It's likely that you are seeing a different path (unload) leading
>>>>> to the
>>>>> same issue.
>>>>>
>>>>> I think in i915_pmu_disable/disable should be aware of event-
>>>>>> hw.state
>>>>> and or pmu->closed states before accessing the event. Maybe like,
>>>>>
>>>>> if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event))
>>>>> {
>>>>>
>>>>> @Tvrtko, wondering if this case is tested by igt@perf
>>>>> _pmu@module-unload.
>>>>
>>>> A bit yes. From what Stuart wrote it seems the test would need to be
>>>> extended to cover the case where PMU is getting opened while module
>>>> unload is in progress.
>>>>
>>>> But the NPD you saw is for the moment confusing so I don't know what
>>>> is
>>>> happening.
>>>>
>>>>> I am not clear if we should use event->hw.state or pmu->closed here
>>>>> and
>>>>> if/how they are related. IMO, for this issue, the engine check is
>>>>> good
>>>>> enough too, so we don't really need the pmu state checks.
>>>>> Thoughts?
>>>>
>>>> Engine check at the moment feels like papering.
>>>>
>>>> Indeed as you say I think the pmu->closed might be the solution.
>>>> Perhaps
>>>> the race is as mentioned above. PMU open happening in parallel to
>>>> unload..
>>>>
>>>> If the sequence of events userspace triggers is:
>>>>
>>>>    i915_pmu_event_init
>>>>    i915_pmu_event_start
>>>>    i915_pmu_enable
>>>>    i915_pmu_event_read
>>>>
>>>> I guess pmu->closed can get set halfway in i915_pmu_event_init. What
>>>> would be the effect of that.. We'd try to get a module reference
>>>> while
>>>> in the process of unloading. Which is probably very bad.. So possibly
>>>> a
>>>> final check on pmu->close is needed there. Ho hum.. can it be made
>>>> safe
>>>> is the question.
>>>>
>>>> It doesn't explain the NPD on Ctrl-C though.. intel_gpu_top keeps
>>>> the
>>>> evens open all the time. So I think more info needed, for me at
>>>> least.
>>>
>>> So one thing here is this doesn't have to do with module unload, but
>>> module unbind specifically (while perf is open). I don't know if the
>>> NPD from Umesh is the same as what we're seeing here. I'd really like
>>> to separate these unless you know for sure that's related. Also it
>>> would be interesting to know if this patch fixes your issue as well.
>>>
>>> I still think the re-ordering in i915_driver.c should be enough and we
>>> shouldn't need to check pmu->closed. The unregister should be enough to
>>> ensure the perf tools are notified that new events aren't allowed, and
>>> at that time the engine structures are still intact. And even if for
>>> some reason the perf code still calls in to our function pointers, we
>>> have these engine checks as a failsafe.
>>>
>>> I'm by the way uploading one more version here with a drm_WARN_ONCE
>>> instead of the debug print.
>>
>> Problem is I am not a fan of papering so lets get to the bottom of the 
>> issue first. (In the meantime simple patch to re-order driver fini is 
>> okay since that seems obvious enough, I tnink.)
>>
>> We need to see call traces from any oopses and try to extend perf_pmu 
>> to catch them. And we need to understand the problem, if it is a real 
>> problem, which I laid out last week about race between module unload 
>> and elevating the module use count from our perf event init.
>>
>> Without understanding the details of possible failure mode flows we 
>> don't know how much the papering with engine checks solves and how 
>> much it leaves broken.
>>
>> If you guys are too busy to tackle that I'll put it onto myself, but 
>> help would certainly be appreciated.
> 
> Looks like Stuart/Chris are pointing towards the unbind as an issue.
> 
> I ran this sequence and only the modprobe showed an error (FATAL: ... 
> still in use). What happens with the unbind. Should pmu also handle the 
> unbind somehow?
> 
> - run intel_gpu_top
> - unbind
> - modprobe -r i915
> - kill intel_gpu_top.

And it crashes or survives in this scenario?

Module still in use here would be expected since intel_gpu_top is 
holding a module reference.

And pmu->closed should be set at the unbind step via i915_pci_remove -> 
i915_driver_unregister -> i915_pmu_unregister.

We also need to try a stress test with two threads:

	Thread A		Thread B
	-----------		-----------
	loop:			loop:
	  open pmu event	  rmmod
	  close pmu event	  insmod

To see if it can hit a problem with drm_dev_get from i915_pmu_event_init 
being called at a bad moment relative to module unload. Maybe I am 
confused but that seems a possibility and a serious problem currently.

Regards,

Tvrtko

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-07-19  9:00           ` Tvrtko Ursulin
@ 2022-07-20  0:22             ` Umesh Nerlige Ramappa
  2022-07-20  8:14               ` Tvrtko Ursulin
  0 siblings, 1 reply; 21+ messages in thread
From: Umesh Nerlige Ramappa @ 2022-07-20  0:22 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

On Tue, Jul 19, 2022 at 10:00:01AM +0100, Tvrtko Ursulin wrote:
>
>On 12/07/2022 22:03, Umesh Nerlige Ramappa wrote:
>>On Mon, Jul 04, 2022 at 09:31:55AM +0100, Tvrtko Ursulin wrote:
>>>
>>>On 01/07/2022 15:54, Summers, Stuart wrote:
>>>>On Fri, 2022-07-01 at 09:37 +0100, Tvrtko Ursulin wrote:
>>>>>On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
>>>>>>On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart Summers wrote:
>>>>>>>In the driver teardown, we are unregistering the gt prior
>>>>>>>to unregistering the PMU. This means there is a small window
>>>>>>>of time in which the application can request metrics from the
>>>>>>>PMU, some of which are calling into the uapi engines list,
>>>>>>>while the engines are not available. In this case we can
>>>>>>>see null pointer dereferences.
>>>>>>>
>>>>>>>Fix this ordering in both the driver load and unload sequences.
>>>>>>>
>>>>>>>Additionally add a check for engine presence to prevent this
>>>>>>>NPD in the event this ordering is accidentally reversed. Print
>>>>>>>a debug message indicating when they aren't available.
>>>>>>>
>>>>>>>v1: Actually address the driver load/unload ordering issue
>>>>>>>
>>>>>>>Signed-off-by: Stuart Summers <stuart.summers@intel.com>
>>>>>>>---
>>>>>>
>>>>>>I thought this is likely happening because intel_gpu_top is running
>>>>>>in
>>>>>>the background when i915 is unloaded. I tried a quick repro, I
>>>>>>don't see
>>>>>>the unload succeed ("fatal module in use", not sure if this was a
>>>>>>partial unload), but when I try to kill intel_gpu_top, I get an
>>>>>>NPD.
>>>>>>This is in the event disable path - i915_pmu_event_stop ->
>>>>>>i915_pmu_disable.
>>>>>
>>>>>So i915 failed to unload (as expected - with perf events open we
>>>>>elevate
>>>>>the module ref count via i915_pmu_event_init -> drm_dev_get), then
>>>>>you
>>>>>quit intel_gpu_top and get NPD? On the engine lookup? With the
>>>>>re-ordered init/fini sequence as from this patch?
>>>>>
>>>>>With elevated module count there shouldn't be any unloading happening
>>>>>so
>>>>>I am intrigued.
>>>>>
>>>>>>It's likely that you are seeing a different path (unload) leading
>>>>>>to the
>>>>>>same issue.
>>>>>>
>>>>>>I think in i915_pmu_disable/disable should be aware of event-
>>>>>>>hw.state
>>>>>>and or pmu->closed states before accessing the event. Maybe like,
>>>>>>
>>>>>>if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event))
>>>>>>{
>>>>>>
>>>>>>@Tvrtko, wondering if this case is tested by igt@perf
>>>>>>_pmu@module-unload.
>>>>>
>>>>>A bit yes. From what Stuart wrote it seems the test would need to be
>>>>>extended to cover the case where PMU is getting opened while module
>>>>>unload is in progress.
>>>>>
>>>>>But the NPD you saw is for the moment confusing so I don't know what
>>>>>is
>>>>>happening.
>>>>>
>>>>>>I am not clear if we should use event->hw.state or pmu->closed here
>>>>>>and
>>>>>>if/how they are related. IMO, for this issue, the engine check is
>>>>>>good
>>>>>>enough too, so we don't really need the pmu state checks.
>>>>>>Thoughts?
>>>>>
>>>>>Engine check at the moment feels like papering.
>>>>>
>>>>>Indeed as you say I think the pmu->closed might be the solution.
>>>>>Perhaps
>>>>>the race is as mentioned above. PMU open happening in parallel to
>>>>>unload..
>>>>>
>>>>>If the sequence of events userspace triggers is:
>>>>>
>>>>>   i915_pmu_event_init
>>>>>   i915_pmu_event_start
>>>>>   i915_pmu_enable
>>>>>   i915_pmu_event_read
>>>>>
>>>>>I guess pmu->closed can get set halfway in i915_pmu_event_init. What
>>>>>would be the effect of that.. We'd try to get a module reference
>>>>>while
>>>>>in the process of unloading. Which is probably very bad.. So possibly
>>>>>a
>>>>>final check on pmu->close is needed there. Ho hum.. can it be made
>>>>>safe
>>>>>is the question.
>>>>>
>>>>>It doesn't explain the NPD on Ctrl-C though.. intel_gpu_top keeps
>>>>>the
>>>>>evens open all the time. So I think more info needed, for me at
>>>>>least.
>>>>
>>>>So one thing here is this doesn't have to do with module unload, but
>>>>module unbind specifically (while perf is open). I don't know if the
>>>>NPD from Umesh is the same as what we're seeing here. I'd really like
>>>>to separate these unless you know for sure that's related. Also it
>>>>would be interesting to know if this patch fixes your issue as well.
>>>>
>>>>I still think the re-ordering in i915_driver.c should be enough and we
>>>>shouldn't need to check pmu->closed. The unregister should be enough to
>>>>ensure the perf tools are notified that new events aren't allowed, and
>>>>at that time the engine structures are still intact. And even if for
>>>>some reason the perf code still calls in to our function pointers, we
>>>>have these engine checks as a failsafe.
>>>>
>>>>I'm by the way uploading one more version here with a drm_WARN_ONCE
>>>>instead of the debug print.
>>>
>>>Problem is I am not a fan of papering so lets get to the bottom of 
>>>the issue first. (In the meantime simple patch to re-order driver 
>>>fini is okay since that seems obvious enough, I tnink.)
>>>
>>>We need to see call traces from any oopses and try to extend 
>>>perf_pmu to catch them. And we need to understand the problem, if 
>>>it is a real problem, which I laid out last week about race 
>>>between module unload and elevating the module use count from our 
>>>perf event init.
>>>
>>>Without understanding the details of possible failure mode flows 
>>>we don't know how much the papering with engine checks solves and 
>>>how much it leaves broken.
>>>
>>>If you guys are too busy to tackle that I'll put it onto myself, 
>>>but help would certainly be appreciated.
>>
>>Looks like Stuart/Chris are pointing towards the unbind as an issue.
>>
>>I ran this sequence and only the modprobe showed an error (FATAL: 
>>... still in use). What happens with the unbind. Should pmu also 
>>handle the unbind somehow?
>>
>>- run intel_gpu_top
>>- unbind
>>- modprobe -r i915
>>- kill intel_gpu_top.
>
>And it crashes or survives in this scenario?

hangs on adlp, haven't been able to get the serial logs

>
>Module still in use here would be expected since intel_gpu_top is 
>holding a module reference.
>
>And pmu->closed should be set at the unbind step via i915_pci_remove 
>-> i915_driver_unregister -> i915_pmu_unregister.

After unbind, 

kill intel_gpu_top -> i915_pmu_event_del -> i915_pmu_event_stop -> 
i915_pmu_disable -> likely HANGs when dereferencing engine.

Can we can short circuit i915_pmu_disable with 

if (pmu->closed)
	return;

since this function is also adjusting pmu->enable_count. Does it matter 
after pmu is closed?

Umesh


>
>We also need to try a stress test with two threads:
>
>	Thread A		Thread B
>	-----------		-----------
>	loop:			loop:
>	  open pmu event	  rmmod
>	  close pmu event	  insmod
>
>To see if it can hit a problem with drm_dev_get from 
>i915_pmu_event_init being called at a bad moment relative to module 
>unload. Maybe I am confused but that seems a possibility and a serious 
>problem currently.
>
>Regards,
>
>Tvrtko

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-07-20  0:22             ` Umesh Nerlige Ramappa
@ 2022-07-20  8:14               ` Tvrtko Ursulin
  2022-07-20 20:07                 ` Umesh Nerlige Ramappa
  0 siblings, 1 reply; 21+ messages in thread
From: Tvrtko Ursulin @ 2022-07-20  8:14 UTC (permalink / raw)
  To: Umesh Nerlige Ramappa; +Cc: intel-gfx


On 20/07/2022 01:22, Umesh Nerlige Ramappa wrote:
> On Tue, Jul 19, 2022 at 10:00:01AM +0100, Tvrtko Ursulin wrote:
>>
>> On 12/07/2022 22:03, Umesh Nerlige Ramappa wrote:
>>> On Mon, Jul 04, 2022 at 09:31:55AM +0100, Tvrtko Ursulin wrote:
>>>>
>>>> On 01/07/2022 15:54, Summers, Stuart wrote:
>>>>> On Fri, 2022-07-01 at 09:37 +0100, Tvrtko Ursulin wrote:
>>>>>> On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
>>>>>>> On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart Summers wrote:
>>>>>>>> In the driver teardown, we are unregistering the gt prior
>>>>>>>> to unregistering the PMU. This means there is a small window
>>>>>>>> of time in which the application can request metrics from the
>>>>>>>> PMU, some of which are calling into the uapi engines list,
>>>>>>>> while the engines are not available. In this case we can
>>>>>>>> see null pointer dereferences.
>>>>>>>>
>>>>>>>> Fix this ordering in both the driver load and unload sequences.
>>>>>>>>
>>>>>>>> Additionally add a check for engine presence to prevent this
>>>>>>>> NPD in the event this ordering is accidentally reversed. Print
>>>>>>>> a debug message indicating when they aren't available.
>>>>>>>>
>>>>>>>> v1: Actually address the driver load/unload ordering issue
>>>>>>>>
>>>>>>>> Signed-off-by: Stuart Summers <stuart.summers@intel.com>
>>>>>>>> ---
>>>>>>>
>>>>>>> I thought this is likely happening because intel_gpu_top is running
>>>>>>> in
>>>>>>> the background when i915 is unloaded. I tried a quick repro, I
>>>>>>> don't see
>>>>>>> the unload succeed ("fatal module in use", not sure if this was a
>>>>>>> partial unload), but when I try to kill intel_gpu_top, I get an
>>>>>>> NPD.
>>>>>>> This is in the event disable path - i915_pmu_event_stop ->
>>>>>>> i915_pmu_disable.
>>>>>>
>>>>>> So i915 failed to unload (as expected - with perf events open we
>>>>>> elevate
>>>>>> the module ref count via i915_pmu_event_init -> drm_dev_get), then
>>>>>> you
>>>>>> quit intel_gpu_top and get NPD? On the engine lookup? With the
>>>>>> re-ordered init/fini sequence as from this patch?
>>>>>>
>>>>>> With elevated module count there shouldn't be any unloading happening
>>>>>> so
>>>>>> I am intrigued.
>>>>>>
>>>>>>> It's likely that you are seeing a different path (unload) leading
>>>>>>> to the
>>>>>>> same issue.
>>>>>>>
>>>>>>> I think in i915_pmu_disable/disable should be aware of event-
>>>>>>>> hw.state
>>>>>>> and or pmu->closed states before accessing the event. Maybe like,
>>>>>>>
>>>>>>> if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event))
>>>>>>> {
>>>>>>>
>>>>>>> @Tvrtko, wondering if this case is tested by igt@perf
>>>>>>> _pmu@module-unload.
>>>>>>
>>>>>> A bit yes. From what Stuart wrote it seems the test would need to be
>>>>>> extended to cover the case where PMU is getting opened while module
>>>>>> unload is in progress.
>>>>>>
>>>>>> But the NPD you saw is for the moment confusing so I don't know what
>>>>>> is
>>>>>> happening.
>>>>>>
>>>>>>> I am not clear if we should use event->hw.state or pmu->closed here
>>>>>>> and
>>>>>>> if/how they are related. IMO, for this issue, the engine check is
>>>>>>> good
>>>>>>> enough too, so we don't really need the pmu state checks.
>>>>>>> Thoughts?
>>>>>>
>>>>>> Engine check at the moment feels like papering.
>>>>>>
>>>>>> Indeed as you say I think the pmu->closed might be the solution.
>>>>>> Perhaps
>>>>>> the race is as mentioned above. PMU open happening in parallel to
>>>>>> unload..
>>>>>>
>>>>>> If the sequence of events userspace triggers is:
>>>>>>
>>>>>>    i915_pmu_event_init
>>>>>>    i915_pmu_event_start
>>>>>>    i915_pmu_enable
>>>>>>    i915_pmu_event_read
>>>>>>
>>>>>> I guess pmu->closed can get set halfway in i915_pmu_event_init. What
>>>>>> would be the effect of that.. We'd try to get a module reference
>>>>>> while
>>>>>> in the process of unloading. Which is probably very bad.. So possibly
>>>>>> a
>>>>>> final check on pmu->close is needed there. Ho hum.. can it be made
>>>>>> safe
>>>>>> is the question.
>>>>>>
>>>>>> It doesn't explain the NPD on Ctrl-C though.. intel_gpu_top keeps
>>>>>> the
>>>>>> evens open all the time. So I think more info needed, for me at
>>>>>> least.
>>>>>
>>>>> So one thing here is this doesn't have to do with module unload, but
>>>>> module unbind specifically (while perf is open). I don't know if the
>>>>> NPD from Umesh is the same as what we're seeing here. I'd really like
>>>>> to separate these unless you know for sure that's related. Also it
>>>>> would be interesting to know if this patch fixes your issue as well.
>>>>>
>>>>> I still think the re-ordering in i915_driver.c should be enough and we
>>>>> shouldn't need to check pmu->closed. The unregister should be 
>>>>> enough to
>>>>> ensure the perf tools are notified that new events aren't allowed, and
>>>>> at that time the engine structures are still intact. And even if for
>>>>> some reason the perf code still calls in to our function pointers, we
>>>>> have these engine checks as a failsafe.
>>>>>
>>>>> I'm by the way uploading one more version here with a drm_WARN_ONCE
>>>>> instead of the debug print.
>>>>
>>>> Problem is I am not a fan of papering so lets get to the bottom of 
>>>> the issue first. (In the meantime simple patch to re-order driver 
>>>> fini is okay since that seems obvious enough, I tnink.)
>>>>
>>>> We need to see call traces from any oopses and try to extend 
>>>> perf_pmu to catch them. And we need to understand the problem, if it 
>>>> is a real problem, which I laid out last week about race between 
>>>> module unload and elevating the module use count from our perf event 
>>>> init.
>>>>
>>>> Without understanding the details of possible failure mode flows we 
>>>> don't know how much the papering with engine checks solves and how 
>>>> much it leaves broken.
>>>>
>>>> If you guys are too busy to tackle that I'll put it onto myself, but 
>>>> help would certainly be appreciated.
>>>
>>> Looks like Stuart/Chris are pointing towards the unbind as an issue.
>>>
>>> I ran this sequence and only the modprobe showed an error (FATAL: ... 
>>> still in use). What happens with the unbind. Should pmu also handle 
>>> the unbind somehow?
>>>
>>> - run intel_gpu_top
>>> - unbind
>>> - modprobe -r i915
>>> - kill intel_gpu_top.
>>
>> And it crashes or survives in this scenario?
> 
> hangs on adlp, haven't been able to get the serial logs
> 
>>
>> Module still in use here would be expected since intel_gpu_top is 
>> holding a module reference.
>>
>> And pmu->closed should be set at the unbind step via i915_pci_remove 
>> -> i915_driver_unregister -> i915_pmu_unregister.
> 
> After unbind,
> kill intel_gpu_top -> i915_pmu_event_del -> i915_pmu_event_stop -> 
> i915_pmu_disable -> likely HANGs when dereferencing engine.
> 
> Can we can short circuit i915_pmu_disable with
> if (pmu->closed)
>      return;
> 
> since this function is also adjusting pmu->enable_count. Does it matter 
> after pmu is closed?

Erm yes.. this sounds obvious now but why I did not put a pmu->closed check in i915_pmu_event_stop, since read and start/init have it!? Was it a simple oversight or something more I can't remember.

Try like this maybe:

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 958b37123bf1..2399adf92cc0 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -760,9 +760,13 @@ static void i915_pmu_event_start(struct perf_event *event, int flags)
  
  static void i915_pmu_event_stop(struct perf_event *event, int flags)
  {
+       if (pmu->closed)
+               goto out;
+
         if (flags & PERF_EF_UPDATE)
                 i915_pmu_event_read(event);
         i915_pmu_disable(event);
+out:
         event->hw.state = PERF_HES_STOPPED;
  }
  

Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind")

Enable count handling in i915_pmu_disable should not matter since the i915_pmu_unregister would have already been executed by this point so all we need to ensure is that pmu->closed is not use after free. And since open event hold the DRM device reference I think that is fine.

Regards,

Tvrtko

> 
> Umesh
> 
> 
>>
>> We also need to try a stress test with two threads:
>>
>>     Thread A        Thread B
>>     -----------        -----------
>>     loop:            loop:
>>       open pmu event      rmmod
>>       close pmu event      insmod
>>
>> To see if it can hit a problem with drm_dev_get from 
>> i915_pmu_event_init being called at a bad moment relative to module 
>> unload. Maybe I am confused but that seems a possibility and a serious 
>> problem currently.
>>
>> Regards,
>>
>> Tvrtko

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-07-20  8:14               ` Tvrtko Ursulin
@ 2022-07-20 20:07                 ` Umesh Nerlige Ramappa
  2022-07-21  4:30                   ` Summers, Stuart
  0 siblings, 1 reply; 21+ messages in thread
From: Umesh Nerlige Ramappa @ 2022-07-20 20:07 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

On Wed, Jul 20, 2022 at 09:14:38AM +0100, Tvrtko Ursulin wrote:
>
>On 20/07/2022 01:22, Umesh Nerlige Ramappa wrote:
>>On Tue, Jul 19, 2022 at 10:00:01AM +0100, Tvrtko Ursulin wrote:
>>>
>>>On 12/07/2022 22:03, Umesh Nerlige Ramappa wrote:
>>>>On Mon, Jul 04, 2022 at 09:31:55AM +0100, Tvrtko Ursulin wrote:
>>>>>
>>>>>On 01/07/2022 15:54, Summers, Stuart wrote:
>>>>>>On Fri, 2022-07-01 at 09:37 +0100, Tvrtko Ursulin wrote:
>>>>>>>On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
>>>>>>>>On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart Summers wrote:
>>>>>>>>>In the driver teardown, we are unregistering the gt prior
>>>>>>>>>to unregistering the PMU. This means there is a small window
>>>>>>>>>of time in which the application can request metrics from the
>>>>>>>>>PMU, some of which are calling into the uapi engines list,
>>>>>>>>>while the engines are not available. In this case we can
>>>>>>>>>see null pointer dereferences.
>>>>>>>>>
>>>>>>>>>Fix this ordering in both the driver load and unload sequences.
>>>>>>>>>
>>>>>>>>>Additionally add a check for engine presence to prevent this
>>>>>>>>>NPD in the event this ordering is accidentally reversed. Print
>>>>>>>>>a debug message indicating when they aren't available.
>>>>>>>>>
>>>>>>>>>v1: Actually address the driver load/unload ordering issue
>>>>>>>>>
>>>>>>>>>Signed-off-by: Stuart Summers <stuart.summers@intel.com>
>>>>>>>>>---
>>>>>>>>
>>>>>>>>I thought this is likely happening because intel_gpu_top is running
>>>>>>>>in
>>>>>>>>the background when i915 is unloaded. I tried a quick repro, I
>>>>>>>>don't see
>>>>>>>>the unload succeed ("fatal module in use", not sure if this was a
>>>>>>>>partial unload), but when I try to kill intel_gpu_top, I get an
>>>>>>>>NPD.
>>>>>>>>This is in the event disable path - i915_pmu_event_stop ->
>>>>>>>>i915_pmu_disable.
>>>>>>>
>>>>>>>So i915 failed to unload (as expected - with perf events open we
>>>>>>>elevate
>>>>>>>the module ref count via i915_pmu_event_init -> drm_dev_get), then
>>>>>>>you
>>>>>>>quit intel_gpu_top and get NPD? On the engine lookup? With the
>>>>>>>re-ordered init/fini sequence as from this patch?
>>>>>>>
>>>>>>>With elevated module count there shouldn't be any unloading happening
>>>>>>>so
>>>>>>>I am intrigued.
>>>>>>>
>>>>>>>>It's likely that you are seeing a different path (unload) leading
>>>>>>>>to the
>>>>>>>>same issue.
>>>>>>>>
>>>>>>>>I think in i915_pmu_disable/disable should be aware of event-
>>>>>>>>>hw.state
>>>>>>>>and or pmu->closed states before accessing the event. Maybe like,
>>>>>>>>
>>>>>>>>if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event))
>>>>>>>>{
>>>>>>>>
>>>>>>>>@Tvrtko, wondering if this case is tested by igt@perf
>>>>>>>>_pmu@module-unload.
>>>>>>>
>>>>>>>A bit yes. From what Stuart wrote it seems the test would need to be
>>>>>>>extended to cover the case where PMU is getting opened while module
>>>>>>>unload is in progress.
>>>>>>>
>>>>>>>But the NPD you saw is for the moment confusing so I don't know what
>>>>>>>is
>>>>>>>happening.
>>>>>>>
>>>>>>>>I am not clear if we should use event->hw.state or pmu->closed here
>>>>>>>>and
>>>>>>>>if/how they are related. IMO, for this issue, the engine check is
>>>>>>>>good
>>>>>>>>enough too, so we don't really need the pmu state checks.
>>>>>>>>Thoughts?
>>>>>>>
>>>>>>>Engine check at the moment feels like papering.
>>>>>>>
>>>>>>>Indeed as you say I think the pmu->closed might be the solution.
>>>>>>>Perhaps
>>>>>>>the race is as mentioned above. PMU open happening in parallel to
>>>>>>>unload..
>>>>>>>
>>>>>>>If the sequence of events userspace triggers is:
>>>>>>>
>>>>>>>   i915_pmu_event_init
>>>>>>>   i915_pmu_event_start
>>>>>>>   i915_pmu_enable
>>>>>>>   i915_pmu_event_read
>>>>>>>
>>>>>>>I guess pmu->closed can get set halfway in i915_pmu_event_init. What
>>>>>>>would be the effect of that.. We'd try to get a module reference
>>>>>>>while
>>>>>>>in the process of unloading. Which is probably very bad.. So possibly
>>>>>>>a
>>>>>>>final check on pmu->close is needed there. Ho hum.. can it be made
>>>>>>>safe
>>>>>>>is the question.
>>>>>>>
>>>>>>>It doesn't explain the NPD on Ctrl-C though.. intel_gpu_top keeps
>>>>>>>the
>>>>>>>evens open all the time. So I think more info needed, for me at
>>>>>>>least.
>>>>>>
>>>>>>So one thing here is this doesn't have to do with module unload, but
>>>>>>module unbind specifically (while perf is open). I don't know if the
>>>>>>NPD from Umesh is the same as what we're seeing here. I'd really like
>>>>>>to separate these unless you know for sure that's related. Also it
>>>>>>would be interesting to know if this patch fixes your issue as well.
>>>>>>
>>>>>>I still think the re-ordering in i915_driver.c should be enough and we
>>>>>>shouldn't need to check pmu->closed. The unregister should 
>>>>>>be enough to
>>>>>>ensure the perf tools are notified that new events aren't allowed, and
>>>>>>at that time the engine structures are still intact. And even if for
>>>>>>some reason the perf code still calls in to our function pointers, we
>>>>>>have these engine checks as a failsafe.
>>>>>>
>>>>>>I'm by the way uploading one more version here with a drm_WARN_ONCE
>>>>>>instead of the debug print.
>>>>>
>>>>>Problem is I am not a fan of papering so lets get to the 
>>>>>bottom of the issue first. (In the meantime simple patch to 
>>>>>re-order driver fini is okay since that seems obvious enough, 
>>>>>I tnink.)
>>>>>
>>>>>We need to see call traces from any oopses and try to extend 
>>>>>perf_pmu to catch them. And we need to understand the problem, 
>>>>>if it is a real problem, which I laid out last week about race 
>>>>>between module unload and elevating the module use count from 
>>>>>our perf event init.
>>>>>
>>>>>Without understanding the details of possible failure mode 
>>>>>flows we don't know how much the papering with engine checks 
>>>>>solves and how much it leaves broken.
>>>>>
>>>>>If you guys are too busy to tackle that I'll put it onto 
>>>>>myself, but help would certainly be appreciated.
>>>>
>>>>Looks like Stuart/Chris are pointing towards the unbind as an issue.
>>>>
>>>>I ran this sequence and only the modprobe showed an error 
>>>>(FATAL: ... still in use). What happens with the unbind. Should 
>>>>pmu also handle the unbind somehow?
>>>>
>>>>- run intel_gpu_top
>>>>- unbind
>>>>- modprobe -r i915
>>>>- kill intel_gpu_top.
>>>
>>>And it crashes or survives in this scenario?
>>
>>hangs on adlp, haven't been able to get the serial logs
>>
>>>
>>>Module still in use here would be expected since intel_gpu_top is 
>>>holding a module reference.
>>>
>>>And pmu->closed should be set at the unbind step via 
>>>i915_pci_remove -> i915_driver_unregister -> i915_pmu_unregister.
>>
>>After unbind,
>>kill intel_gpu_top -> i915_pmu_event_del -> i915_pmu_event_stop -> 
>>i915_pmu_disable -> likely HANGs when dereferencing engine.
>>
>>Can we can short circuit i915_pmu_disable with
>>if (pmu->closed)
>>     return;
>>
>>since this function is also adjusting pmu->enable_count. Does it 
>>matter after pmu is closed?
>
>Erm yes.. this sounds obvious now but why I did not put a pmu->closed check in i915_pmu_event_stop, since read and start/init have it!? Was it a simple oversight or something more I can't remember.
>
>Try like this maybe:
>
>diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
>index 958b37123bf1..2399adf92cc0 100644
>--- a/drivers/gpu/drm/i915/i915_pmu.c
>+++ b/drivers/gpu/drm/i915/i915_pmu.c
>@@ -760,9 +760,13 @@ static void i915_pmu_event_start(struct perf_event *event, int flags)
> static void i915_pmu_event_stop(struct perf_event *event, int flags)
> {
>+       if (pmu->closed)
>+               goto out;
>+
>        if (flags & PERF_EF_UPDATE)
>                i915_pmu_event_read(event);
>        i915_pmu_disable(event);
>+out:
>        event->hw.state = PERF_HES_STOPPED;
> }
>
>Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind")

that works. I don't see a hang with the above sequence on ADLP. Do you 
want to post/merge this?

Also what about Stuart's changes in this series. At a minimum, I would 
keep the engine checks in i915_pmu_disable (rev1)? I am not sure the 
reorder of pmu/gt registrations is needed though.

Thanks,
Umesh

>
>Enable count handling in i915_pmu_disable should not matter since the i915_pmu_unregister would have already been executed by this point so all we need to ensure is that pmu->closed is not use after free. And since open event hold the DRM device reference I think that is fine.
>
>Regards,
>
>Tvrtko
>
>>
>>Umesh
>>
>>
>>>
>>>We also need to try a stress test with two threads:
>>>
>>>    Thread A        Thread B
>>>    -----------        -----------
>>>    loop:            loop:
>>>      open pmu event      rmmod
>>>      close pmu event      insmod
>>>
>>>To see if it can hit a problem with drm_dev_get from 
>>>i915_pmu_event_init being called at a bad moment relative to 
>>>module unload. Maybe I am confused but that seems a possibility 
>>>and a serious problem currently.
>>>
>>>Regards,
>>>
>>>Tvrtko

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-07-20 20:07                 ` Umesh Nerlige Ramappa
@ 2022-07-21  4:30                   ` Summers, Stuart
  2022-07-21  7:43                     ` Tvrtko Ursulin
  0 siblings, 1 reply; 21+ messages in thread
From: Summers, Stuart @ 2022-07-21  4:30 UTC (permalink / raw)
  To: Nerlige Ramappa, Umesh, tvrtko.ursulin; +Cc: intel-gfx

On Wed, 2022-07-20 at 13:07 -0700, Umesh Nerlige Ramappa wrote:
> On Wed, Jul 20, 2022 at 09:14:38AM +0100, Tvrtko Ursulin wrote:
> > On 20/07/2022 01:22, Umesh Nerlige Ramappa wrote:
> > > On Tue, Jul 19, 2022 at 10:00:01AM +0100, Tvrtko Ursulin wrote:
> > > > On 12/07/2022 22:03, Umesh Nerlige Ramappa wrote:
> > > > > On Mon, Jul 04, 2022 at 09:31:55AM +0100, Tvrtko Ursulin
> > > > > wrote:
> > > > > > On 01/07/2022 15:54, Summers, Stuart wrote:
> > > > > > > On Fri, 2022-07-01 at 09:37 +0100, Tvrtko Ursulin wrote:
> > > > > > > > On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
> > > > > > > > > On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart
> > > > > > > > > Summers wrote:
> > > > > > > > > > In the driver teardown, we are unregistering the gt
> > > > > > > > > > prior
> > > > > > > > > > to unregistering the PMU. This means there is a
> > > > > > > > > > small window
> > > > > > > > > > of time in which the application can request
> > > > > > > > > > metrics from the
> > > > > > > > > > PMU, some of which are calling into the uapi
> > > > > > > > > > engines list,
> > > > > > > > > > while the engines are not available. In this case
> > > > > > > > > > we can
> > > > > > > > > > see null pointer dereferences.
> > > > > > > > > > 
> > > > > > > > > > Fix this ordering in both the driver load and
> > > > > > > > > > unload sequences.
> > > > > > > > > > 
> > > > > > > > > > Additionally add a check for engine presence to
> > > > > > > > > > prevent this
> > > > > > > > > > NPD in the event this ordering is accidentally
> > > > > > > > > > reversed. Print
> > > > > > > > > > a debug message indicating when they aren't
> > > > > > > > > > available.
> > > > > > > > > > 
> > > > > > > > > > v1: Actually address the driver load/unload
> > > > > > > > > > ordering issue
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Stuart Summers <
> > > > > > > > > > stuart.summers@intel.com>
> > > > > > > > > > ---
> > > > > > > > > 
> > > > > > > > > I thought this is likely happening because
> > > > > > > > > intel_gpu_top is running
> > > > > > > > > in
> > > > > > > > > the background when i915 is unloaded. I tried a quick
> > > > > > > > > repro, I
> > > > > > > > > don't see
> > > > > > > > > the unload succeed ("fatal module in use", not sure
> > > > > > > > > if this was a
> > > > > > > > > partial unload), but when I try to kill
> > > > > > > > > intel_gpu_top, I get an
> > > > > > > > > NPD.
> > > > > > > > > This is in the event disable path -
> > > > > > > > > i915_pmu_event_stop ->
> > > > > > > > > i915_pmu_disable.
> > > > > > > > 
> > > > > > > > So i915 failed to unload (as expected - with perf
> > > > > > > > events open we
> > > > > > > > elevate
> > > > > > > > the module ref count via i915_pmu_event_init ->
> > > > > > > > drm_dev_get), then
> > > > > > > > you
> > > > > > > > quit intel_gpu_top and get NPD? On the engine lookup?
> > > > > > > > With the
> > > > > > > > re-ordered init/fini sequence as from this patch?
> > > > > > > > 
> > > > > > > > With elevated module count there shouldn't be any
> > > > > > > > unloading happening
> > > > > > > > so
> > > > > > > > I am intrigued.
> > > > > > > > 
> > > > > > > > > It's likely that you are seeing a different path
> > > > > > > > > (unload) leading
> > > > > > > > > to the
> > > > > > > > > same issue.
> > > > > > > > > 
> > > > > > > > > I think in i915_pmu_disable/disable should be aware
> > > > > > > > > of event-
> > > > > > > > > > hw.state
> > > > > > > > > and or pmu->closed states before accessing the event.
> > > > > > > > > Maybe like,
> > > > > > > > > 
> > > > > > > > > if (event->hw.state != PERF_HES_STOPPED &&
> > > > > > > > > is_engine_event(event))
> > > > > > > > > {
> > > > > > > > > 
> > > > > > > > > @Tvrtko, wondering if this case is tested by igt@perf
> > > > > > > > > _pmu@module-unload.
> > > > > > > > 
> > > > > > > > A bit yes. From what Stuart wrote it seems the test
> > > > > > > > would need to be
> > > > > > > > extended to cover the case where PMU is getting opened
> > > > > > > > while module
> > > > > > > > unload is in progress.
> > > > > > > > 
> > > > > > > > But the NPD you saw is for the moment confusing so I
> > > > > > > > don't know what
> > > > > > > > is
> > > > > > > > happening.
> > > > > > > > 
> > > > > > > > > I am not clear if we should use event->hw.state or
> > > > > > > > > pmu->closed here
> > > > > > > > > and
> > > > > > > > > if/how they are related. IMO, for this issue, the
> > > > > > > > > engine check is
> > > > > > > > > good
> > > > > > > > > enough too, so we don't really need the pmu state
> > > > > > > > > checks.
> > > > > > > > > Thoughts?
> > > > > > > > 
> > > > > > > > Engine check at the moment feels like papering.
> > > > > > > > 
> > > > > > > > Indeed as you say I think the pmu->closed might be the
> > > > > > > > solution.
> > > > > > > > Perhaps
> > > > > > > > the race is as mentioned above. PMU open happening in
> > > > > > > > parallel to
> > > > > > > > unload..
> > > > > > > > 
> > > > > > > > If the sequence of events userspace triggers is:
> > > > > > > > 
> > > > > > > >    i915_pmu_event_init
> > > > > > > >    i915_pmu_event_start
> > > > > > > >    i915_pmu_enable
> > > > > > > >    i915_pmu_event_read
> > > > > > > > 
> > > > > > > > I guess pmu->closed can get set halfway in
> > > > > > > > i915_pmu_event_init. What
> > > > > > > > would be the effect of that.. We'd try to get a module
> > > > > > > > reference
> > > > > > > > while
> > > > > > > > in the process of unloading. Which is probably very
> > > > > > > > bad.. So possibly
> > > > > > > > a
> > > > > > > > final check on pmu->close is needed there. Ho hum.. can
> > > > > > > > it be made
> > > > > > > > safe
> > > > > > > > is the question.
> > > > > > > > 
> > > > > > > > It doesn't explain the NPD on Ctrl-C though..
> > > > > > > > intel_gpu_top keeps
> > > > > > > > the
> > > > > > > > evens open all the time. So I think more info needed,
> > > > > > > > for me at
> > > > > > > > least.
> > > > > > > 
> > > > > > > So one thing here is this doesn't have to do with module
> > > > > > > unload, but
> > > > > > > module unbind specifically (while perf is open). I don't
> > > > > > > know if the
> > > > > > > NPD from Umesh is the same as what we're seeing here. I'd
> > > > > > > really like
> > > > > > > to separate these unless you know for sure that's
> > > > > > > related. Also it
> > > > > > > would be interesting to know if this patch fixes your
> > > > > > > issue as well.
> > > > > > > 
> > > > > > > I still think the re-ordering in i915_driver.c should be
> > > > > > > enough and we
> > > > > > > shouldn't need to check pmu->closed. The unregister
> > > > > > > should 
> > > > > > > be enough to
> > > > > > > ensure the perf tools are notified that new events aren't
> > > > > > > allowed, and
> > > > > > > at that time the engine structures are still intact. And
> > > > > > > even if for
> > > > > > > some reason the perf code still calls in to our function
> > > > > > > pointers, we
> > > > > > > have these engine checks as a failsafe.
> > > > > > > 
> > > > > > > I'm by the way uploading one more version here with a
> > > > > > > drm_WARN_ONCE
> > > > > > > instead of the debug print.
> > > > > > 
> > > > > > Problem is I am not a fan of papering so lets get to the 
> > > > > > bottom of the issue first. (In the meantime simple patch
> > > > > > to 
> > > > > > re-order driver fini is okay since that seems obvious
> > > > > > enough, 
> > > > > > I tnink.)
> > > > > > 
> > > > > > We need to see call traces from any oopses and try to
> > > > > > extend 
> > > > > > perf_pmu to catch them. And we need to understand the
> > > > > > problem, 
> > > > > > if it is a real problem, which I laid out last week about
> > > > > > race 
> > > > > > between module unload and elevating the module use count
> > > > > > from 
> > > > > > our perf event init.
> > > > > > 
> > > > > > Without understanding the details of possible failure mode 
> > > > > > flows we don't know how much the papering with engine
> > > > > > checks 
> > > > > > solves and how much it leaves broken.
> > > > > > 
> > > > > > If you guys are too busy to tackle that I'll put it onto 
> > > > > > myself, but help would certainly be appreciated.
> > > > > 
> > > > > Looks like Stuart/Chris are pointing towards the unbind as an
> > > > > issue.
> > > > > 
> > > > > I ran this sequence and only the modprobe showed an error 
> > > > > (FATAL: ... still in use). What happens with the unbind.
> > > > > Should 
> > > > > pmu also handle the unbind somehow?
> > > > > 
> > > > > - run intel_gpu_top
> > > > > - unbind
> > > > > - modprobe -r i915
> > > > > - kill intel_gpu_top.
> > > > 
> > > > And it crashes or survives in this scenario?
> > > 
> > > hangs on adlp, haven't been able to get the serial logs
> > > 
> > > > Module still in use here would be expected since intel_gpu_top
> > > > is 
> > > > holding a module reference.
> > > > 
> > > > And pmu->closed should be set at the unbind step via 
> > > > i915_pci_remove -> i915_driver_unregister ->
> > > > i915_pmu_unregister.
> > > 
> > > After unbind,
> > > kill intel_gpu_top -> i915_pmu_event_del -> i915_pmu_event_stop
> > > -> 
> > > i915_pmu_disable -> likely HANGs when dereferencing engine.
> > > 
> > > Can we can short circuit i915_pmu_disable with
> > > if (pmu->closed)
> > >     return;
> > > 
> > > since this function is also adjusting pmu->enable_count. Does it 
> > > matter after pmu is closed?
> > 
> > Erm yes.. this sounds obvious now but why I did not put a pmu-
> > >closed check in i915_pmu_event_stop, since read and start/init
> > have it!? Was it a simple oversight or something more I can't
> > remember.
> > 
> > Try like this maybe:
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > b/drivers/gpu/drm/i915/i915_pmu.c
> > index 958b37123bf1..2399adf92cc0 100644
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -760,9 +760,13 @@ static void i915_pmu_event_start(struct
> > perf_event *event, int flags)
> > static void i915_pmu_event_stop(struct perf_event *event, int
> > flags)
> > {
> > +       if (pmu->closed)
> > +               goto out;
> > +
> >        if (flags & PERF_EF_UPDATE)
> >                i915_pmu_event_read(event);
> >        i915_pmu_disable(event);
> > +out:
> >        event->hw.state = PERF_HES_STOPPED;
> > }
> > 
> > Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind")
> 
> that works. I don't see a hang with the above sequence on ADLP. Do
> you 
> want to post/merge this?
> 
> Also what about Stuart's changes in this series. At a minimum, I
> would 
> keep the engine checks in i915_pmu_disable (rev1)? I am not sure the 
> reorder of pmu/gt registrations is needed though.

Thanks for the help here Tvrtko/Umesh! Sorry for the late reply here.
I've been swamped and haven't been able to get back here.

IMO we really should have all three of these, possibly in three
separate patches. I'm happy to post any or all of these or one of you
can - happy to review. It will be earliest some time tomorrow though.

Thanks,
Stuart

> 
> Thanks,
> Umesh
> 
> > Enable count handling in i915_pmu_disable should not matter since
> > the i915_pmu_unregister would have already been executed by this
> > point so all we need to ensure is that pmu->closed is not use after
> > free. And since open event hold the DRM device reference I think
> > that is fine.
> > 
> > Regards,
> > 
> > Tvrtko
> > 
> > > Umesh
> > > 
> > > 
> > > > We also need to try a stress test with two threads:
> > > > 
> > > >     Thread A        Thread B
> > > >     -----------        -----------
> > > >     loop:            loop:
> > > >       open pmu event      rmmod
> > > >       close pmu event      insmod
> > > > 
> > > > To see if it can hit a problem with drm_dev_get from 
> > > > i915_pmu_event_init being called at a bad moment relative to 
> > > > module unload. Maybe I am confused but that seems a
> > > > possibility 
> > > > and a serious problem currently.
> > > > 
> > > > Regards,
> > > > 
> > > > Tvrtko

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-07-21  4:30                   ` Summers, Stuart
@ 2022-07-21  7:43                     ` Tvrtko Ursulin
  2022-08-03 22:54                       ` Summers, Stuart
  0 siblings, 1 reply; 21+ messages in thread
From: Tvrtko Ursulin @ 2022-07-21  7:43 UTC (permalink / raw)
  To: Summers, Stuart, Nerlige Ramappa, Umesh; +Cc: intel-gfx


On 21/07/2022 05:30, Summers, Stuart wrote:
> On Wed, 2022-07-20 at 13:07 -0700, Umesh Nerlige Ramappa wrote:
>> On Wed, Jul 20, 2022 at 09:14:38AM +0100, Tvrtko Ursulin wrote:
>>> On 20/07/2022 01:22, Umesh Nerlige Ramappa wrote:
>>>> On Tue, Jul 19, 2022 at 10:00:01AM +0100, Tvrtko Ursulin wrote:
>>>>> On 12/07/2022 22:03, Umesh Nerlige Ramappa wrote:
>>>>>> On Mon, Jul 04, 2022 at 09:31:55AM +0100, Tvrtko Ursulin
>>>>>> wrote:
>>>>>>> On 01/07/2022 15:54, Summers, Stuart wrote:
>>>>>>>> On Fri, 2022-07-01 at 09:37 +0100, Tvrtko Ursulin wrote:
>>>>>>>>> On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
>>>>>>>>>> On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart
>>>>>>>>>> Summers wrote:
>>>>>>>>>>> In the driver teardown, we are unregistering the gt
>>>>>>>>>>> prior
>>>>>>>>>>> to unregistering the PMU. This means there is a
>>>>>>>>>>> small window
>>>>>>>>>>> of time in which the application can request
>>>>>>>>>>> metrics from the
>>>>>>>>>>> PMU, some of which are calling into the uapi
>>>>>>>>>>> engines list,
>>>>>>>>>>> while the engines are not available. In this case
>>>>>>>>>>> we can
>>>>>>>>>>> see null pointer dereferences.
>>>>>>>>>>>
>>>>>>>>>>> Fix this ordering in both the driver load and
>>>>>>>>>>> unload sequences.
>>>>>>>>>>>
>>>>>>>>>>> Additionally add a check for engine presence to
>>>>>>>>>>> prevent this
>>>>>>>>>>> NPD in the event this ordering is accidentally
>>>>>>>>>>> reversed. Print
>>>>>>>>>>> a debug message indicating when they aren't
>>>>>>>>>>> available.
>>>>>>>>>>>
>>>>>>>>>>> v1: Actually address the driver load/unload
>>>>>>>>>>> ordering issue
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Stuart Summers <
>>>>>>>>>>> stuart.summers@intel.com>not yet been able to force a failure on a system with lots of RAM. My dev system has 32G of ram, and I have not been able to arrive at the level of memory pressure to apply which causes the gem cache to exceed the system memory without being killed by OOM first.
>>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> I thought this is likely happening because
>>>>>>>>>> intel_gpu_top is running
>>>>>>>>>> in
>>>>>>>>>> the background when i915 is unloaded. I tried a quick
>>>>>>>>>> repro, I
>>>>>>>>>> don't see
>>>>>>>>>> the unload succeed ("fatal module in use", not sure
>>>>>>>>>> if this was a
>>>>>>>>>> partial unload), but when I try to kill
>>>>>>>>>> intel_gpu_top, I get an
>>>>>>>>>> NPD.
>>>>>>>>>> This is in the event disable path -
>>>>>>>>>> i915_pmu_event_stop ->
>>>>>>>>>> i915_pmu_disable.
>>>>>>>>>
>>>>>>>>> So i915 failed to unload (as expected - with perf
>>>>>>>>> events open we
>>>>>>>>> elevate
>>>>>>>>> the module ref count via i915_pmu_event_init ->
>>>>>>>>> drm_dev_get), then
>>>>>>>>> you
>>>>>>>>> quit intel_gpu_top and get NPD? On the engine lookup?
>>>>>>>>> With the
>>>>>>>>> re-ordered init/fini sequence as from this patch?
>>>>>>>>>
>>>>>>>>> With elevated module count there shouldn't be any
>>>>>>>>> unloading happening
>>>>>>>>> so
>>>>>>>>> I am intrigued.
>>>>>>>>>
>>>>>>>>>> It's likely that you are seeing a different path
>>>>>>>>>> (unload) leading
>>>>>>>>>> to the
>>>>>>>>>> same issue.
>>>>>>>>>>
>>>>>>>>>> I think in i915_pmu_disable/disable should be aware
>>>>>>>>>> of event-
>>>>>>>>>>> hw.state
>>>>>>>>>> and or pmu->closed states before accessing the event.
>>>>>>>>>> Maybe like,
>>>>>>>>>>
>>>>>>>>>> if (event->hw.state != PERF_HES_STOPPED &&
>>>>>>>>>> is_engine_event(event))
>>>>>>>>>> {
>>>>>>>>>>
>>>>>>>>>> @Tvrtko, wondering if this case is tested by igt@perf
>>>>>>>>>> _pmu@module-unload.
>>>>>>>>>
>>>>>>>>> A bit yes. From what Stuart wrote it seems the test
>>>>>>>>> would need to be
>>>>>>>>> extended to cover the case where PMU is getting opened
>>>>>>>>> while module
>>>>>>>>> unload is in progress.
>>>>>>>>>
>>>>>>>>> But the NPD you saw is for the moment confusing so I
>>>>>>>>> don't know what
>>>>>>>>> is
>>>>>>>>> happening.
>>>>>>>>>
>>>>>>>>>> I am not clear if we should use event->hw.state or
>>>>>>>>>> pmu->closed here
>>>>>>>>>> and
>>>>>>>>>> if/how they are related. IMO, for this issue, the
>>>>>>>>>> engine check is
>>>>>>>>>> good
>>>>>>>>>> enough too, so we don't really need the pmu state
>>>>>>>>>> checks.
>>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> Engine check at the moment feels like papering.
>>>>>>>>>
>>>>>>>>> Indeed as you say I think the pmu->closed might be the
>>>>>>>>> solution.
>>>>>>>>> Perhaps
>>>>>>>>> the race is as mentioned above. PMU open happening in
>>>>>>>>> parallel to
>>>>>>>>> unload..
>>>>>>>>>
>>>>>>>>> If the sequence of events userspace triggers is:
>>>>>>>>>
>>>>>>>>>     i915_pmu_event_init
>>>>>>>>>     i915_pmu_event_start
>>>>>>>>>     i915_pmu_enable
>>>>>>>>>     i915_pmu_event_read
>>>>>>>>>
>>>>>>>>> I guess pmu->closed can get set halfway in
>>>>>>>>> i915_pmu_event_init. What
>>>>>>>>> would be the effect of that.. We'd try to get a module
>>>>>>>>> reference
>>>>>>>>> while
>>>>>>>>> in the process of unloading. Which is probably very
>>>>>>>>> bad.. So possibly
>>>>>>>>> a
>>>>>>>>> final check on pmu->close is needed there. Ho hum.. can
>>>>>>>>> it be made
>>>>>>>>> safe
>>>>>>>>> is the question.
>>>>>>>>>
>>>>>>>>> It doesn't explain the NPD on Ctrl-C though..
>>>>>>>>> intel_gpu_top keeps
>>>>>>>>> the
>>>>>>>>> evens open all the time. So I think more info needed,
>>>>>>>>> for me at
>>>>>>>>> least.
>>>>>>>>
>>>>>>>> So one thing here is this doesn't have to do with module
>>>>>>>> unload, but
>>>>>>>> module unbind specifically (while perf is open). I don't
>>>>>>>> know if the
>>>>>>>> NPD from Umesh is the same as what we're seeing here. I'd
>>>>>>>> really like
>>>>>>>> to separate these unless you know for sure that's
>>>>>>>> related. Also it
>>>>>>>> would be interesting to know if this patch fixes your
>>>>>>>> issue as well.
>>>>>>>>
>>>>>>>> I still think the re-ordering in i915_driver.c should be
>>>>>>>> enough and we
>>>>>>>> shouldn't need to check pmu->closed. The unregister
>>>>>>>> should
>>>>>>>> be enough to
>>>>>>>> ensure the perf tools are notified that new events aren't
>>>>>>>> allowed, and
>>>>>>>> at that time the engine structures are still intact. And
>>>>>>>> even if for
>>>>>>>> some reason the perf code still calls in to our function
>>>>>>>> pointers, we
>>>>>>>> have these engine checks as a failsafe.
>>>>>>>>
>>>>>>>> I'm by the way uploading one more version here with a
>>>>>>>> drm_WARN_ONCE
>>>>>>>> instead of the debug print.
>>>>>>>
>>>>>>> Problem is I am not a fan of papering so lets get to the
>>>>>>> bottom of the issue first. (In the meantime simple patch
>>>>>>> to
>>>>>>> re-order driver fini is okay since that seems obvious
>>>>>>> enough,
>>>>>>> I tnink.)
>>>>>>>
>>>>>>> We need to see call traces from any oopses and try to
>>>>>>> extend
>>>>>>> perf_pmu to catch them. And we need to understand the
>>>>>>> problem,
>>>>>>> if it is a real problem, which I laid out last week about
>>>>>>> race
>>>>>>> between module unload and elevating the module use count
>>>>>>> from
>>>>>>> our perf event init.
>>>>>>>
>>>>>>> Without understanding the details of possible failure mode
>>>>>>> flows we don't know how much the papering with engine
>>>>>>> checks
>>>>>>> solves and how much it leaves broken.
>>>>>>>
>>>>>>> If you guys are too busy to tackle that I'll put it onto
>>>>>>> myself, but help would certainly be appreciated.
>>>>>>
>>>>>> Looks like Stuart/Chris are pointing towards the unbind as an
>>>>>> issue.
>>>>>>
>>>>>> I ran this sequence and only the modprobe showed an error
>>>>>> (FATAL: ... still in use). What happens with the unbind.
>>>>>> Should
>>>>>> pmu also handle the unbind somehow?
>>>>>>
>>>>>> - run intel_gpu_top
>>>>>> - unbind
>>>>>> - modprobe -r i915
>>>>>> - kill intel_gpu_top.
>>>>>
>>>>> And it crashes or survives in this scenario?
>>>>
>>>> hangs on adlp, haven't been able to get the serial logs
>>>>
>>>>> Module still in use here would be expected since intel_gpu_top
>>>>> is
>>>>> holding a module reference.
>>>>>
>>>>> And pmu->closed should be set at the unbind step via
>>>>> i915_pci_remove -> i915_driver_unregister ->
>>>>> i915_pmu_unregister.
>>>>
>>>> After unbind,
>>>> kill intel_gpu_top -> i915_pmu_event_del -> i915_pmu_event_stop
>>>> ->
>>>> i915_pmu_disable -> likely HANGs when dereferencing engine.
>>>>
>>>> Can we can short circuit i915_pmu_disable with
>>>> if (pmu->closed)
>>>>      return;
>>>>
>>>> since this function is also adjusting pmu->enable_count. Does it
>>>> matter after pmu is closed?
>>>
>>> Erm yes.. this sounds obvious now but why I did not put a pmu-
>>>> closed check in i915_pmu_event_stop, since read and start/init
>>> have it!? Was it a simple oversight or something more I can't
>>> remember.
>>>
>>> Try like this maybe:
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_pmu.c
>>> b/drivers/gpu/drm/i915/i915_pmu.c
>>> index 958b37123bf1..2399adf92cc0 100644
>>> --- a/drivers/gpu/drm/i915/i915_pmu.c
>>> +++ b/drivers/gpu/drm/i915/i915_pmu.c
>>> @@ -760,9 +760,13 @@ static void i915_pmu_event_start(struct
>>> perf_event *event, int flags)
>>> static void i915_pmu_event_stop(struct perf_event *event, int
>>> flags)
>>> {
>>> +       if (pmu->closed)
>>> +               goto out;
>>> +
>>>         if (flags & PERF_EF_UPDATE)
>>>                 i915_pmu_event_read(event);
>>>         i915_pmu_disable(event);
>>> +out:
>>>         event->hw.state = PERF_HES_STOPPED;
>>> }
>>>
>>> Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind")
>>
>> that works. I don't see a hang with the above sequence on ADLP. Do
>> you
>> want to post/merge this?
>>
>> Also what about Stuart's changes in this series. At a minimum, I
>> would
>> keep the engine checks in i915_pmu_disable (rev1)? I am not sure the
>> reorder of pmu/gt registrations is needed though.
> 
> Thanks for the help here Tvrtko/Umesh! Sorry for the late reply here.
> I've been swamped and haven't been able to get back here.
> 
> IMO we really should have all three of these, possibly in three
> separate patches. I'm happy to post any or all of these or one of you
> can - happy to review. It will be earliest some time tomorrow though.

Re-order on unbind path AFAIR yes, and pmu->closed check in either 
i915_pmu_event_stop or early return from i915_pmu_disable (I was going 
for symmetry with start, but perhaps it looks clumsy, not sure) yes. 
Those two should have a fixes tag as well. Null engine checks I still do 
not support. It adds a production build debug string for something which 
is supposed to be impossible and a programming error, and makes the code 
a bit uglier with the extra indentation.

Regards,

Tvrtko

> 
> Thanks,
> Stuart
> 
>>
>> Thanks,
>> Umesh
>>
>>> Enable count handling in i915_pmu_disable should not matter since
>>> the i915_pmu_unregister would have already been executed by this
>>> point so all we need to ensure is that pmu->closed is not use after
>>> free. And since open event hold the DRM device reference I think
>>> that is fine.
>>>
>>> Regards,
>>>
>>> Tvrtko
>>>
>>>> Umesh
>>>>
>>>>
>>>>> We also need to try a stress test with two threads:
>>>>>
>>>>>      Thread A        Thread B
>>>>>      -----------        -----------
>>>>>      loop:            loop:
>>>>>        open pmu event      rmmod
>>>>>        close pmu event      insmod
>>>>>
>>>>> To see if it can hit a problem with drm_dev_get from
>>>>> i915_pmu_event_init being called at a bad moment relative to
>>>>> module unload. Maybe I am confused but that seems a
>>>>> possibility
>>>>> and a serious problem currently.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Tvrtko

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-07-21  7:43                     ` Tvrtko Ursulin
@ 2022-08-03 22:54                       ` Summers, Stuart
  0 siblings, 0 replies; 21+ messages in thread
From: Summers, Stuart @ 2022-08-03 22:54 UTC (permalink / raw)
  To: Nerlige Ramappa, Umesh, tvrtko.ursulin; +Cc: intel-gfx

On Thu, 2022-07-21 at 08:43 +0100, Tvrtko Ursulin wrote:
> On 21/07/2022 05:30, Summers, Stuart wrote:
> > On Wed, 2022-07-20 at 13:07 -0700, Umesh Nerlige Ramappa wrote:
> > > On Wed, Jul 20, 2022 at 09:14:38AM +0100, Tvrtko Ursulin wrote:
> > > > On 20/07/2022 01:22, Umesh Nerlige Ramappa wrote:
> > > > > On Tue, Jul 19, 2022 at 10:00:01AM +0100, Tvrtko Ursulin
> > > > > wrote:
> > > > > > On 12/07/2022 22:03, Umesh Nerlige Ramappa wrote:
> > > > > > > On Mon, Jul 04, 2022 at 09:31:55AM +0100, Tvrtko Ursulin
> > > > > > > wrote:
> > > > > > > > On 01/07/2022 15:54, Summers, Stuart wrote:
> > > > > > > > > On Fri, 2022-07-01 at 09:37 +0100, Tvrtko Ursulin
> > > > > > > > > wrote:
> > > > > > > > > > On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
> > > > > > > > > > > On Thu, Jun 30, 2022 at 09:00:28PM +0000, Stuart
> > > > > > > > > > > Summers wrote:
> > > > > > > > > > > > In the driver teardown, we are unregistering
> > > > > > > > > > > > the gt
> > > > > > > > > > > > prior
> > > > > > > > > > > > to unregistering the PMU. This means there is a
> > > > > > > > > > > > small window
> > > > > > > > > > > > of time in which the application can request
> > > > > > > > > > > > metrics from the
> > > > > > > > > > > > PMU, some of which are calling into the uapi
> > > > > > > > > > > > engines list,
> > > > > > > > > > > > while the engines are not available. In this
> > > > > > > > > > > > case
> > > > > > > > > > > > we can
> > > > > > > > > > > > see null pointer dereferences.
> > > > > > > > > > > > 
> > > > > > > > > > > > Fix this ordering in both the driver load and
> > > > > > > > > > > > unload sequences.
> > > > > > > > > > > > 
> > > > > > > > > > > > Additionally add a check for engine presence to
> > > > > > > > > > > > prevent this
> > > > > > > > > > > > NPD in the event this ordering is accidentally
> > > > > > > > > > > > reversed. Print
> > > > > > > > > > > > a debug message indicating when they aren't
> > > > > > > > > > > > available.
> > > > > > > > > > > > 
> > > > > > > > > > > > v1: Actually address the driver load/unload
> > > > > > > > > > > > ordering issue
> > > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Stuart Summers <
> > > > > > > > > > > > stuart.summers@intel.com>not yet been able to
> > > > > > > > > > > > force a failure on a system with lots of RAM.
> > > > > > > > > > > > My dev system has 32G of ram, and I have not
> > > > > > > > > > > > been able to arrive at the level of memory
> > > > > > > > > > > > pressure to apply which causes the gem cache to
> > > > > > > > > > > > exceed the system memory without being killed
> > > > > > > > > > > > by OOM first.
> > > > > > > > > > > > ---
> > > > > > > > > > > 
> > > > > > > > > > > I thought this is likely happening because
> > > > > > > > > > > intel_gpu_top is running
> > > > > > > > > > > in
> > > > > > > > > > > the background when i915 is unloaded. I tried a
> > > > > > > > > > > quick
> > > > > > > > > > > repro, I
> > > > > > > > > > > don't see
> > > > > > > > > > > the unload succeed ("fatal module in use", not
> > > > > > > > > > > sure
> > > > > > > > > > > if this was a
> > > > > > > > > > > partial unload), but when I try to kill
> > > > > > > > > > > intel_gpu_top, I get an
> > > > > > > > > > > NPD.
> > > > > > > > > > > This is in the event disable path -
> > > > > > > > > > > i915_pmu_event_stop ->
> > > > > > > > > > > i915_pmu_disable.
> > > > > > > > > > 
> > > > > > > > > > So i915 failed to unload (as expected - with perf
> > > > > > > > > > events open we
> > > > > > > > > > elevate
> > > > > > > > > > the module ref count via i915_pmu_event_init ->
> > > > > > > > > > drm_dev_get), then
> > > > > > > > > > you
> > > > > > > > > > quit intel_gpu_top and get NPD? On the engine
> > > > > > > > > > lookup?
> > > > > > > > > > With the
> > > > > > > > > > re-ordered init/fini sequence as from this patch?
> > > > > > > > > > 
> > > > > > > > > > With elevated module count there shouldn't be any
> > > > > > > > > > unloading happening
> > > > > > > > > > so
> > > > > > > > > > I am intrigued.
> > > > > > > > > > 
> > > > > > > > > > > It's likely that you are seeing a different path
> > > > > > > > > > > (unload) leading
> > > > > > > > > > > to the
> > > > > > > > > > > same issue.
> > > > > > > > > > > 
> > > > > > > > > > > I think in i915_pmu_disable/disable should be
> > > > > > > > > > > aware
> > > > > > > > > > > of event-
> > > > > > > > > > > > hw.state
> > > > > > > > > > > and or pmu->closed states before accessing the
> > > > > > > > > > > event.
> > > > > > > > > > > Maybe like,
> > > > > > > > > > > 
> > > > > > > > > > > if (event->hw.state != PERF_HES_STOPPED &&
> > > > > > > > > > > is_engine_event(event))
> > > > > > > > > > > {
> > > > > > > > > > > 
> > > > > > > > > > > @Tvrtko, wondering if this case is tested by 
> > > > > > > > > > > igt@perf
> > > > > > > > > > > _pmu@module-unload.
> > > > > > > > > > 
> > > > > > > > > > A bit yes. From what Stuart wrote it seems the test
> > > > > > > > > > would need to be
> > > > > > > > > > extended to cover the case where PMU is getting
> > > > > > > > > > opened
> > > > > > > > > > while module
> > > > > > > > > > unload is in progress.
> > > > > > > > > > 
> > > > > > > > > > But the NPD you saw is for the moment confusing so
> > > > > > > > > > I
> > > > > > > > > > don't know what
> > > > > > > > > > is
> > > > > > > > > > happening.
> > > > > > > > > > 
> > > > > > > > > > > I am not clear if we should use event->hw.state
> > > > > > > > > > > or
> > > > > > > > > > > pmu->closed here
> > > > > > > > > > > and
> > > > > > > > > > > if/how they are related. IMO, for this issue, the
> > > > > > > > > > > engine check is
> > > > > > > > > > > good
> > > > > > > > > > > enough too, so we don't really need the pmu state
> > > > > > > > > > > checks.
> > > > > > > > > > > Thoughts?
> > > > > > > > > > 
> > > > > > > > > > Engine check at the moment feels like papering.
> > > > > > > > > > 
> > > > > > > > > > Indeed as you say I think the pmu->closed might be
> > > > > > > > > > the
> > > > > > > > > > solution.
> > > > > > > > > > Perhaps
> > > > > > > > > > the race is as mentioned above. PMU open happening
> > > > > > > > > > in
> > > > > > > > > > parallel to
> > > > > > > > > > unload..
> > > > > > > > > > 
> > > > > > > > > > If the sequence of events userspace triggers is:
> > > > > > > > > > 
> > > > > > > > > >     i915_pmu_event_init
> > > > > > > > > >     i915_pmu_event_start
> > > > > > > > > >     i915_pmu_enable
> > > > > > > > > >     i915_pmu_event_read
> > > > > > > > > > 
> > > > > > > > > > I guess pmu->closed can get set halfway in
> > > > > > > > > > i915_pmu_event_init. What
> > > > > > > > > > would be the effect of that.. We'd try to get a
> > > > > > > > > > module
> > > > > > > > > > reference
> > > > > > > > > > while
> > > > > > > > > > in the process of unloading. Which is probably very
> > > > > > > > > > bad.. So possibly
> > > > > > > > > > a
> > > > > > > > > > final check on pmu->close is needed there. Ho hum..
> > > > > > > > > > can
> > > > > > > > > > it be made
> > > > > > > > > > safe
> > > > > > > > > > is the question.
> > > > > > > > > > 
> > > > > > > > > > It doesn't explain the NPD on Ctrl-C though..
> > > > > > > > > > intel_gpu_top keeps
> > > > > > > > > > the
> > > > > > > > > > evens open all the time. So I think more info
> > > > > > > > > > needed,
> > > > > > > > > > for me at
> > > > > > > > > > least.
> > > > > > > > > 
> > > > > > > > > So one thing here is this doesn't have to do with
> > > > > > > > > module
> > > > > > > > > unload, but
> > > > > > > > > module unbind specifically (while perf is open). I
> > > > > > > > > don't
> > > > > > > > > know if the
> > > > > > > > > NPD from Umesh is the same as what we're seeing here.
> > > > > > > > > I'd
> > > > > > > > > really like
> > > > > > > > > to separate these unless you know for sure that's
> > > > > > > > > related. Also it
> > > > > > > > > would be interesting to know if this patch fixes your
> > > > > > > > > issue as well.
> > > > > > > > > 
> > > > > > > > > I still think the re-ordering in i915_driver.c should
> > > > > > > > > be
> > > > > > > > > enough and we
> > > > > > > > > shouldn't need to check pmu->closed. The unregister
> > > > > > > > > should
> > > > > > > > > be enough to
> > > > > > > > > ensure the perf tools are notified that new events
> > > > > > > > > aren't
> > > > > > > > > allowed, and
> > > > > > > > > at that time the engine structures are still intact.
> > > > > > > > > And
> > > > > > > > > even if for
> > > > > > > > > some reason the perf code still calls in to our
> > > > > > > > > function
> > > > > > > > > pointers, we
> > > > > > > > > have these engine checks as a failsafe.
> > > > > > > > > 
> > > > > > > > > I'm by the way uploading one more version here with a
> > > > > > > > > drm_WARN_ONCE
> > > > > > > > > instead of the debug print.
> > > > > > > > 
> > > > > > > > Problem is I am not a fan of papering so lets get to
> > > > > > > > the
> > > > > > > > bottom of the issue first. (In the meantime simple
> > > > > > > > patch
> > > > > > > > to
> > > > > > > > re-order driver fini is okay since that seems obvious
> > > > > > > > enough,
> > > > > > > > I tnink.)
> > > > > > > > 
> > > > > > > > We need to see call traces from any oopses and try to
> > > > > > > > extend
> > > > > > > > perf_pmu to catch them. And we need to understand the
> > > > > > > > problem,
> > > > > > > > if it is a real problem, which I laid out last week
> > > > > > > > about
> > > > > > > > race
> > > > > > > > between module unload and elevating the module use
> > > > > > > > count
> > > > > > > > from
> > > > > > > > our perf event init.
> > > > > > > > 
> > > > > > > > Without understanding the details of possible failure
> > > > > > > > mode
> > > > > > > > flows we don't know how much the papering with engine
> > > > > > > > checks
> > > > > > > > solves and how much it leaves broken.
> > > > > > > > 
> > > > > > > > If you guys are too busy to tackle that I'll put it
> > > > > > > > onto
> > > > > > > > myself, but help would certainly be appreciated.
> > > > > > > 
> > > > > > > Looks like Stuart/Chris are pointing towards the unbind
> > > > > > > as an
> > > > > > > issue.
> > > > > > > 
> > > > > > > I ran this sequence and only the modprobe showed an error
> > > > > > > (FATAL: ... still in use). What happens with the unbind.
> > > > > > > Should
> > > > > > > pmu also handle the unbind somehow?
> > > > > > > 
> > > > > > > - run intel_gpu_top
> > > > > > > - unbind
> > > > > > > - modprobe -r i915
> > > > > > > - kill intel_gpu_top.
> > > > > > 
> > > > > > And it crashes or survives in this scenario?
> > > > > 
> > > > > hangs on adlp, haven't been able to get the serial logs
> > > > > 
> > > > > > Module still in use here would be expected since
> > > > > > intel_gpu_top
> > > > > > is
> > > > > > holding a module reference.
> > > > > > 
> > > > > > And pmu->closed should be set at the unbind step via
> > > > > > i915_pci_remove -> i915_driver_unregister ->
> > > > > > i915_pmu_unregister.
> > > > > 
> > > > > After unbind,
> > > > > kill intel_gpu_top -> i915_pmu_event_del ->
> > > > > i915_pmu_event_stop
> > > > > ->
> > > > > i915_pmu_disable -> likely HANGs when dereferencing engine.
> > > > > 
> > > > > Can we can short circuit i915_pmu_disable with
> > > > > if (pmu->closed)
> > > > >      return;
> > > > > 
> > > > > since this function is also adjusting pmu->enable_count. Does
> > > > > it
> > > > > matter after pmu is closed?
> > > > 
> > > > Erm yes.. this sounds obvious now but why I did not put a pmu-
> > > > > closed check in i915_pmu_event_stop, since read and
> > > > > start/init
> > > > have it!? Was it a simple oversight or something more I can't
> > > > remember.
> > > > 
> > > > Try like this maybe:
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > > > b/drivers/gpu/drm/i915/i915_pmu.c
> > > > index 958b37123bf1..2399adf92cc0 100644
> > > > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > > > @@ -760,9 +760,13 @@ static void i915_pmu_event_start(struct
> > > > perf_event *event, int flags)
> > > > static void i915_pmu_event_stop(struct perf_event *event, int
> > > > flags)
> > > > {
> > > > +       if (pmu->closed)
> > > > +               goto out;
> > > > +
> > > >         if (flags & PERF_EF_UPDATE)
> > > >                 i915_pmu_event_read(event);
> > > >         i915_pmu_disable(event);
> > > > +out:
> > > >         event->hw.state = PERF_HES_STOPPED;
> > > > }
> > > > 
> > > > Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind")
> > > 
> > > that works. I don't see a hang with the above sequence on ADLP.
> > > Do
> > > you
> > > want to post/merge this?
> > > 
> > > Also what about Stuart's changes in this series. At a minimum, I
> > > would
> > > keep the engine checks in i915_pmu_disable (rev1)? I am not sure
> > > the
> > > reorder of pmu/gt registrations is needed though.
> > 
> > Thanks for the help here Tvrtko/Umesh! Sorry for the late reply
> > here.
> > I've been swamped and haven't been able to get back here.
> > 
> > IMO we really should have all three of these, possibly in three
> > separate patches. I'm happy to post any or all of these or one of
> > you
> > can - happy to review. It will be earliest some time tomorrow
> > though.
> 
> Re-order on unbind path AFAIR yes, and pmu->closed check in either 
> i915_pmu_event_stop or early return from i915_pmu_disable (I was
> going 
> for symmetry with start, but perhaps it looks clumsy, not sure) yes. 
> Those two should have a fixes tag as well. Null engine checks I still
> do 
> not support. It adds a production build debug string for something
> which 
> is supposed to be impossible and a programming error, and makes the
> code 
> a bit uglier with the extra indentation.

No problem dropping it.

And I'll post the other two here shortly. I'm going to stick with your
first suggestion on that second patch since I'd otherwise have to add a
couple of skips to avoid the bad pmu-> accesses. And I of course agree
with the symmetry.

Thanks,
Stuart

> 
> Regards,
> 
> Tvrtko
> 
> > Thanks,
> > Stuart
> > 
> > > Thanks,
> > > Umesh
> > > 
> > > > Enable count handling in i915_pmu_disable should not matter
> > > > since
> > > > the i915_pmu_unregister would have already been executed by
> > > > this
> > > > point so all we need to ensure is that pmu->closed is not use
> > > > after
> > > > free. And since open event hold the DRM device reference I
> > > > think
> > > > that is fine.
> > > > 
> > > > Regards,
> > > > 
> > > > Tvrtko
> > > > 
> > > > > Umesh
> > > > > 
> > > > > 
> > > > > > We also need to try a stress test with two threads:
> > > > > > 
> > > > > >      Thread A        Thread B
> > > > > >      -----------        -----------
> > > > > >      loop:            loop:
> > > > > >        open pmu event      rmmod
> > > > > >        close pmu event      insmod
> > > > > > 
> > > > > > To see if it can hit a problem with drm_dev_get from
> > > > > > i915_pmu_event_init being called at a bad moment relative
> > > > > > to
> > > > > > module unload. Maybe I am confused but that seems a
> > > > > > possibility
> > > > > > and a serious problem currently.
> > > > > > 
> > > > > > Regards,
> > > > > > 
> > > > > > Tvrtko

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
@ 2022-07-01 16:15 Stuart Summers
  0 siblings, 0 replies; 21+ messages in thread
From: Stuart Summers @ 2022-07-01 16:15 UTC (permalink / raw)
  Cc: intel-gfx

In the driver teardown, we are unregistering the gt prior
to unregistering the PMU. This means there is a small window
of time in which the application can request metrics from the
PMU, some of which are calling into the uapi engines list,
while the engines are not available. In this case we can
see null pointer dereferences.

Fix this ordering in both the driver load and unload sequences.

Additionally add a check for engine presence to prevent this
NPD in the event this ordering is accidentally reversed. Print
a debug message indicating when they aren't available.

v1: Actually address the driver load/unload ordering issue
v2: Use drm_WARN_ONCE instead of a debug print

Signed-off-by: Stuart Summers <stuart.summers@intel.com>
---
 drivers/gpu/drm/i915/i915_driver.c | 11 ++---
 drivers/gpu/drm/i915/i915_pmu.c    | 70 +++++++++++++++++-------------
 2 files changed, 46 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
index deb8a8b76965..ee4dcb85d206 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -717,7 +717,6 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
 	struct drm_device *dev = &dev_priv->drm;
 
 	i915_gem_driver_register(dev_priv);
-	i915_pmu_register(dev_priv);
 
 	intel_vgpu_register(dev_priv);
 
@@ -731,11 +730,12 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
 	i915_debugfs_register(dev_priv);
 	i915_setup_sysfs(dev_priv);
 
+	intel_gt_driver_register(to_gt(dev_priv));
+
 	/* Depends on sysfs having been initialized */
+	i915_pmu_register(dev_priv);
 	i915_perf_register(dev_priv);
 
-	intel_gt_driver_register(to_gt(dev_priv));
-
 	intel_display_driver_register(dev_priv);
 
 	intel_power_domains_enable(dev_priv);
@@ -762,11 +762,12 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv)
 
 	intel_display_driver_unregister(dev_priv);
 
-	intel_gt_driver_unregister(to_gt(dev_priv));
-
 	i915_perf_unregister(dev_priv);
+	/* GT should be available until PMU is gone */
 	i915_pmu_unregister(dev_priv);
 
+	intel_gt_driver_unregister(to_gt(dev_priv));
+
 	i915_teardown_sysfs(dev_priv);
 	drm_dev_unplug(&dev_priv->drm);
 
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 958b37123bf1..adc81f5293d3 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -670,21 +670,27 @@ static void i915_pmu_enable(struct perf_event *event)
 	if (is_engine_event(event)) {
 		u8 sample = engine_event_sample(event);
 		struct intel_engine_cs *engine;
-
-		engine = intel_engine_lookup_user(i915,
-						  engine_event_class(event),
-						  engine_event_instance(event));
-
-		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
-			     I915_ENGINE_SAMPLE_COUNT);
-		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
-			     I915_ENGINE_SAMPLE_COUNT);
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
-		GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
-
-		engine->pmu.enable |= BIT(sample);
-		engine->pmu.enable_count[sample]++;
+		u8 class = engine_event_class(event);
+		u8 instance = engine_event_instance(event);
+
+		engine = intel_engine_lookup_user(i915, class, instance);
+		if (!drm_WARN_ONCE(&i915->drm,
+				   !engine,
+				   "Invalid engine event: { class:%d, inst:%d }\n",
+				   class, instance)) {
+			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
+				     I915_ENGINE_SAMPLE_COUNT);
+			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
+				     I915_ENGINE_SAMPLE_COUNT);
+			GEM_BUG_ON(sample >=
+				   ARRAY_SIZE(engine->pmu.enable_count));
+			GEM_BUG_ON(sample >=
+				   ARRAY_SIZE(engine->pmu.sample));
+			GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
+
+			engine->pmu.enable |= BIT(sample);
+			engine->pmu.enable_count[sample]++;
+		}
 	}
 
 	spin_unlock_irqrestore(&pmu->lock, flags);
@@ -714,21 +720,25 @@ static void i915_pmu_disable(struct perf_event *event)
 	if (is_engine_event(event)) {
 		u8 sample = engine_event_sample(event);
 		struct intel_engine_cs *engine;
-
-		engine = intel_engine_lookup_user(i915,
-						  engine_event_class(event),
-						  engine_event_instance(event));
-
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
-		GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
-
-		/*
-		 * Decrement the reference count and clear the enabled
-		 * bitmask when the last listener on an event goes away.
-		 */
-		if (--engine->pmu.enable_count[sample] == 0)
-			engine->pmu.enable &= ~BIT(sample);
+		u8 class = engine_event_class(event);
+		u8 instance = engine_event_instance(event);
+
+		engine = intel_engine_lookup_user(i915, class, instance);
+		if (!drm_WARN_ONCE(&i915->drm,
+				   !engine,
+				   "Invalid engine event: { class:%d, inst:%d }\n",
+				   class, instance)) {
+			GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
+			GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
+			GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
+
+			/*
+			 * Decrement the reference count and clear the enabled
+			 * bitmask when the last listener on an event goes away.
+			 */
+			if (--engine->pmu.enable_count[sample] == 0)
+				engine->pmu.enable &= ~BIT(sample);
+		}
 	}
 
 	GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
@ 2022-06-30 22:45 Stuart Summers
  0 siblings, 0 replies; 21+ messages in thread
From: Stuart Summers @ 2022-06-30 22:45 UTC (permalink / raw)
  Cc: intel-gfx

In the driver teardown, we are unregistering the gt prior
to unregistering the PMU. This means there is a small window
of time in which the application can request metrics from the
PMU, some of which are calling into the uapi engines list,
while the engines are not available. In this case we can
see null pointer dereferences.

Fix this ordering in both the driver load and unload sequences.

Additionally add a check for engine presence to prevent this
NPD in the event this ordering is accidentally reversed. Print
a debug message indicating when they aren't available.

v1: Actually address the driver load/unload ordering issue
v2: Use drm_WARN_ONCE instead of a debug print

Signed-off-by: Stuart Summers <stuart.summers@intel.com>
---
 drivers/gpu/drm/i915/i915_driver.c | 11 ++---
 drivers/gpu/drm/i915/i915_pmu.c    | 70 +++++++++++++++++-------------
 2 files changed, 46 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
index deb8a8b76965..ee4dcb85d206 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -717,7 +717,6 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
 	struct drm_device *dev = &dev_priv->drm;
 
 	i915_gem_driver_register(dev_priv);
-	i915_pmu_register(dev_priv);
 
 	intel_vgpu_register(dev_priv);
 
@@ -731,11 +730,12 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
 	i915_debugfs_register(dev_priv);
 	i915_setup_sysfs(dev_priv);
 
+	intel_gt_driver_register(to_gt(dev_priv));
+
 	/* Depends on sysfs having been initialized */
+	i915_pmu_register(dev_priv);
 	i915_perf_register(dev_priv);
 
-	intel_gt_driver_register(to_gt(dev_priv));
-
 	intel_display_driver_register(dev_priv);
 
 	intel_power_domains_enable(dev_priv);
@@ -762,11 +762,12 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv)
 
 	intel_display_driver_unregister(dev_priv);
 
-	intel_gt_driver_unregister(to_gt(dev_priv));
-
 	i915_perf_unregister(dev_priv);
+	/* GT should be available until PMU is gone */
 	i915_pmu_unregister(dev_priv);
 
+	intel_gt_driver_unregister(to_gt(dev_priv));
+
 	i915_teardown_sysfs(dev_priv);
 	drm_dev_unplug(&dev_priv->drm);
 
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 958b37123bf1..adc81f5293d3 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -670,21 +670,27 @@ static void i915_pmu_enable(struct perf_event *event)
 	if (is_engine_event(event)) {
 		u8 sample = engine_event_sample(event);
 		struct intel_engine_cs *engine;
-
-		engine = intel_engine_lookup_user(i915,
-						  engine_event_class(event),
-						  engine_event_instance(event));
-
-		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
-			     I915_ENGINE_SAMPLE_COUNT);
-		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
-			     I915_ENGINE_SAMPLE_COUNT);
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
-		GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
-
-		engine->pmu.enable |= BIT(sample);
-		engine->pmu.enable_count[sample]++;
+		u8 class = engine_event_class(event);
+		u8 instance = engine_event_instance(event);
+
+		engine = intel_engine_lookup_user(i915, class, instance);
+		if (!drm_WARN_ONCE(&i915->drm,
+				   !engine,
+				   "Invalid engine event: { class:%d, inst:%d }\n",
+				   class, instance)) {
+			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
+				     I915_ENGINE_SAMPLE_COUNT);
+			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
+				     I915_ENGINE_SAMPLE_COUNT);
+			GEM_BUG_ON(sample >=
+				   ARRAY_SIZE(engine->pmu.enable_count));
+			GEM_BUG_ON(sample >=
+				   ARRAY_SIZE(engine->pmu.sample));
+			GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
+
+			engine->pmu.enable |= BIT(sample);
+			engine->pmu.enable_count[sample]++;
+		}
 	}
 
 	spin_unlock_irqrestore(&pmu->lock, flags);
@@ -714,21 +720,25 @@ static void i915_pmu_disable(struct perf_event *event)
 	if (is_engine_event(event)) {
 		u8 sample = engine_event_sample(event);
 		struct intel_engine_cs *engine;
-
-		engine = intel_engine_lookup_user(i915,
-						  engine_event_class(event),
-						  engine_event_instance(event));
-
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
-		GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
-
-		/*
-		 * Decrement the reference count and clear the enabled
-		 * bitmask when the last listener on an event goes away.
-		 */
-		if (--engine->pmu.enable_count[sample] == 0)
-			engine->pmu.enable &= ~BIT(sample);
+		u8 class = engine_event_class(event);
+		u8 instance = engine_event_instance(event);
+
+		engine = intel_engine_lookup_user(i915, class, instance);
+		if (!drm_WARN_ONCE(&i915->drm,
+				   !engine,
+				   "Invalid engine event: { class:%d, inst:%d }\n",
+				   class, instance)) {
+			GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
+			GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
+			GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
+
+			/*
+			 * Decrement the reference count and clear the enabled
+			 * bitmask when the last listener on an event goes away.
+			 */
+			if (--engine->pmu.enable_count[sample] == 0)
+				engine->pmu.enable &= ~BIT(sample);
+		}
 	}
 
 	GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-06-30 10:29 ` Tvrtko Ursulin
@ 2022-06-30 19:04   ` Summers, Stuart
  0 siblings, 0 replies; 21+ messages in thread
From: Summers, Stuart @ 2022-06-30 19:04 UTC (permalink / raw)
  To: tvrtko.ursulin; +Cc: intel-gfx

On Thu, 2022-06-30 at 11:29 +0100, Tvrtko Ursulin wrote:
> On 29/06/2022 19:46, Stuart Summers wrote:
> > In the driver teardown, we are unregistering the gt prior
> > to unregistering the PMU. This means there is a small window
> > of time in which the application can request metrics from the
> > PMU, some of which are calling into the uapi engines list,
> > while the engines are not available. In this case we can
> > see null pointer dereferences.
> > 
> > Prevent this by simply checking if the engines are present
> > when those PMU events come through. Print a debug message
> > indicating when they aren't available.
> 
> Obvious question - can we just move PMU unregister PMU to before 
> unregister GT?

Well I wanted to push the workaround asap to get feedback. I submitted
to trybot in parallel and it looks valid. I agree that's a more valid
solution, but IMO we should have these checks anyway.

At any rate, I'll resubmit with the move of the registrations.

Thanks,
Stuart

> 
> Regards,
> 
> Tvrtko
> 
> > Signed-off-by: Stuart Summers <stuart.summers@intel.com>
> > ---
> >   drivers/gpu/drm/i915/i915_pmu.c | 72 +++++++++++++++++++---------
> > -----
> >   1 file changed, 42 insertions(+), 30 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > b/drivers/gpu/drm/i915/i915_pmu.c
> > index 958b37123bf1..796a1d8e36f2 100644
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -670,21 +670,28 @@ static void i915_pmu_enable(struct perf_event
> > *event)
> >   	if (is_engine_event(event)) {
> >   		u8 sample = engine_event_sample(event);
> >   		struct intel_engine_cs *engine;
> > -
> > -		engine = intel_engine_lookup_user(i915,
> > -						  engine_event_class(ev
> > ent),
> > -						  engine_event_instance
> > (event));
> > -
> > -		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
> > -			     I915_ENGINE_SAMPLE_COUNT);
> > -		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
> > -			     I915_ENGINE_SAMPLE_COUNT);
> > -		GEM_BUG_ON(sample >= ARRAY_SIZE(engine-
> > >pmu.enable_count));
> > -		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
> > -		GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
> > -
> > -		engine->pmu.enable |= BIT(sample);
> > -		engine->pmu.enable_count[sample]++;
> > +		u8 class = engine_event_class(event);
> > +		u8 instance = engine_event_instance(event);
> > +
> > +		engine = intel_engine_lookup_user(i915, class,
> > instance);
> > +		if (engine) {
> > +			BUILD_BUG_ON(ARRAY_SIZE(engine-
> > >pmu.enable_count) !=
> > +				     I915_ENGINE_SAMPLE_COUNT);
> > +			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
> > +				     I915_ENGINE_SAMPLE_COUNT);
> > +			GEM_BUG_ON(sample >=
> > +				   ARRAY_SIZE(engine-
> > >pmu.enable_count));
> > +			GEM_BUG_ON(sample >=
> > +				   ARRAY_SIZE(engine->pmu.sample));
> > +			GEM_BUG_ON(engine->pmu.enable_count[sample] ==
> > ~0);
> > +
> > +			engine->pmu.enable |= BIT(sample);
> > +			engine->pmu.enable_count[sample]++;
> > +		} else {
> > +			drm_dbg(&i915->drm,
> > +				"Invalid engine event: { class:%d,
> > inst:%d }\n",
> > +				class, instance);
> > +		}
> >   	}
> >   
> >   	spin_unlock_irqrestore(&pmu->lock, flags);
> > @@ -714,21 +721,26 @@ static void i915_pmu_disable(struct
> > perf_event *event)
> >   	if (is_engine_event(event)) {
> >   		u8 sample = engine_event_sample(event);
> >   		struct intel_engine_cs *engine;
> > -
> > -		engine = intel_engine_lookup_user(i915,
> > -						  engine_event_class(ev
> > ent),
> > -						  engine_event_instance
> > (event));
> > -
> > -		GEM_BUG_ON(sample >= ARRAY_SIZE(engine-
> > >pmu.enable_count));
> > -		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
> > -		GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
> > -
> > -		/*
> > -		 * Decrement the reference count and clear the enabled
> > -		 * bitmask when the last listener on an event goes
> > away.
> > -		 */
> > -		if (--engine->pmu.enable_count[sample] == 0)
> > -			engine->pmu.enable &= ~BIT(sample);
> > +		u8 class = engine_event_class(event);
> > +		u8 instance = engine_event_instance(event);
> > +
> > +		engine = intel_engine_lookup_user(i915, class,
> > instance);
> > +		if (engine) {
> > +			GEM_BUG_ON(sample >= ARRAY_SIZE(engine-
> > >pmu.enable_count));
> > +			GEM_BUG_ON(sample >= ARRAY_SIZE(engine-
> > >pmu.sample));
> > +			GEM_BUG_ON(engine->pmu.enable_count[sample] ==
> > 0);
> > +
> > +			/*
> > +			 * Decrement the reference count and clear the
> > enabled
> > +			 * bitmask when the last listener on an event
> > goes away.
> > +			 */
> > +			if (--engine->pmu.enable_count[sample] == 0)
> > +				engine->pmu.enable &= ~BIT(sample);
> > +		} else {
> > +			drm_dbg(&i915->drm,
> > +				"Invalid engine event: { class:%d,
> > inst:%d }\n",
> > +				class, instance);
> > +		}
> >   	}
> >   
> >   	GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
  2022-06-29 18:46 Stuart Summers
@ 2022-06-30 10:29 ` Tvrtko Ursulin
  2022-06-30 19:04   ` Summers, Stuart
  0 siblings, 1 reply; 21+ messages in thread
From: Tvrtko Ursulin @ 2022-06-30 10:29 UTC (permalink / raw)
  To: Stuart Summers; +Cc: intel-gfx


On 29/06/2022 19:46, Stuart Summers wrote:
> In the driver teardown, we are unregistering the gt prior
> to unregistering the PMU. This means there is a small window
> of time in which the application can request metrics from the
> PMU, some of which are calling into the uapi engines list,
> while the engines are not available. In this case we can
> see null pointer dereferences.
> 
> Prevent this by simply checking if the engines are present
> when those PMU events come through. Print a debug message
> indicating when they aren't available.

Obvious question - can we just move PMU unregister PMU to before 
unregister GT?

Regards,

Tvrtko

> Signed-off-by: Stuart Summers <stuart.summers@intel.com>
> ---
>   drivers/gpu/drm/i915/i915_pmu.c | 72 +++++++++++++++++++--------------
>   1 file changed, 42 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 958b37123bf1..796a1d8e36f2 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -670,21 +670,28 @@ static void i915_pmu_enable(struct perf_event *event)
>   	if (is_engine_event(event)) {
>   		u8 sample = engine_event_sample(event);
>   		struct intel_engine_cs *engine;
> -
> -		engine = intel_engine_lookup_user(i915,
> -						  engine_event_class(event),
> -						  engine_event_instance(event));
> -
> -		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
> -			     I915_ENGINE_SAMPLE_COUNT);
> -		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
> -			     I915_ENGINE_SAMPLE_COUNT);
> -		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
> -		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
> -		GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
> -
> -		engine->pmu.enable |= BIT(sample);
> -		engine->pmu.enable_count[sample]++;
> +		u8 class = engine_event_class(event);
> +		u8 instance = engine_event_instance(event);
> +
> +		engine = intel_engine_lookup_user(i915, class, instance);
> +		if (engine) {
> +			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
> +				     I915_ENGINE_SAMPLE_COUNT);
> +			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
> +				     I915_ENGINE_SAMPLE_COUNT);
> +			GEM_BUG_ON(sample >=
> +				   ARRAY_SIZE(engine->pmu.enable_count));
> +			GEM_BUG_ON(sample >=
> +				   ARRAY_SIZE(engine->pmu.sample));
> +			GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
> +
> +			engine->pmu.enable |= BIT(sample);
> +			engine->pmu.enable_count[sample]++;
> +		} else {
> +			drm_dbg(&i915->drm,
> +				"Invalid engine event: { class:%d, inst:%d }\n",
> +				class, instance);
> +		}
>   	}
>   
>   	spin_unlock_irqrestore(&pmu->lock, flags);
> @@ -714,21 +721,26 @@ static void i915_pmu_disable(struct perf_event *event)
>   	if (is_engine_event(event)) {
>   		u8 sample = engine_event_sample(event);
>   		struct intel_engine_cs *engine;
> -
> -		engine = intel_engine_lookup_user(i915,
> -						  engine_event_class(event),
> -						  engine_event_instance(event));
> -
> -		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
> -		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
> -		GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
> -
> -		/*
> -		 * Decrement the reference count and clear the enabled
> -		 * bitmask when the last listener on an event goes away.
> -		 */
> -		if (--engine->pmu.enable_count[sample] == 0)
> -			engine->pmu.enable &= ~BIT(sample);
> +		u8 class = engine_event_class(event);
> +		u8 instance = engine_event_instance(event);
> +
> +		engine = intel_engine_lookup_user(i915, class, instance);
> +		if (engine) {
> +			GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
> +			GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
> +			GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
> +
> +			/*
> +			 * Decrement the reference count and clear the enabled
> +			 * bitmask when the last listener on an event goes away.
> +			 */
> +			if (--engine->pmu.enable_count[sample] == 0)
> +				engine->pmu.enable &= ~BIT(sample);
> +		} else {
> +			drm_dbg(&i915->drm,
> +				"Invalid engine event: { class:%d, inst:%d }\n",
> +				class, instance);
> +		}
>   	}
>   
>   	GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown
@ 2022-06-29 18:46 Stuart Summers
  2022-06-30 10:29 ` Tvrtko Ursulin
  0 siblings, 1 reply; 21+ messages in thread
From: Stuart Summers @ 2022-06-29 18:46 UTC (permalink / raw)
  Cc: intel-gfx

In the driver teardown, we are unregistering the gt prior
to unregistering the PMU. This means there is a small window
of time in which the application can request metrics from the
PMU, some of which are calling into the uapi engines list,
while the engines are not available. In this case we can
see null pointer dereferences.

Prevent this by simply checking if the engines are present
when those PMU events come through. Print a debug message
indicating when they aren't available.

Signed-off-by: Stuart Summers <stuart.summers@intel.com>
---
 drivers/gpu/drm/i915/i915_pmu.c | 72 +++++++++++++++++++--------------
 1 file changed, 42 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 958b37123bf1..796a1d8e36f2 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -670,21 +670,28 @@ static void i915_pmu_enable(struct perf_event *event)
 	if (is_engine_event(event)) {
 		u8 sample = engine_event_sample(event);
 		struct intel_engine_cs *engine;
-
-		engine = intel_engine_lookup_user(i915,
-						  engine_event_class(event),
-						  engine_event_instance(event));
-
-		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
-			     I915_ENGINE_SAMPLE_COUNT);
-		BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
-			     I915_ENGINE_SAMPLE_COUNT);
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
-		GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
-
-		engine->pmu.enable |= BIT(sample);
-		engine->pmu.enable_count[sample]++;
+		u8 class = engine_event_class(event);
+		u8 instance = engine_event_instance(event);
+
+		engine = intel_engine_lookup_user(i915, class, instance);
+		if (engine) {
+			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
+				     I915_ENGINE_SAMPLE_COUNT);
+			BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
+				     I915_ENGINE_SAMPLE_COUNT);
+			GEM_BUG_ON(sample >=
+				   ARRAY_SIZE(engine->pmu.enable_count));
+			GEM_BUG_ON(sample >=
+				   ARRAY_SIZE(engine->pmu.sample));
+			GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
+
+			engine->pmu.enable |= BIT(sample);
+			engine->pmu.enable_count[sample]++;
+		} else {
+			drm_dbg(&i915->drm,
+				"Invalid engine event: { class:%d, inst:%d }\n",
+				class, instance);
+		}
 	}
 
 	spin_unlock_irqrestore(&pmu->lock, flags);
@@ -714,21 +721,26 @@ static void i915_pmu_disable(struct perf_event *event)
 	if (is_engine_event(event)) {
 		u8 sample = engine_event_sample(event);
 		struct intel_engine_cs *engine;
-
-		engine = intel_engine_lookup_user(i915,
-						  engine_event_class(event),
-						  engine_event_instance(event));
-
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
-		GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
-		GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
-
-		/*
-		 * Decrement the reference count and clear the enabled
-		 * bitmask when the last listener on an event goes away.
-		 */
-		if (--engine->pmu.enable_count[sample] == 0)
-			engine->pmu.enable &= ~BIT(sample);
+		u8 class = engine_event_class(event);
+		u8 instance = engine_event_instance(event);
+
+		engine = intel_engine_lookup_user(i915, class, instance);
+		if (engine) {
+			GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
+			GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
+			GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
+
+			/*
+			 * Decrement the reference count and clear the enabled
+			 * bitmask when the last listener on an event goes away.
+			 */
+			if (--engine->pmu.enable_count[sample] == 0)
+				engine->pmu.enable &= ~BIT(sample);
+		} else {
+			drm_dbg(&i915->drm,
+				"Invalid engine event: { class:%d, inst:%d }\n",
+				class, instance);
+		}
 	}
 
 	GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2022-08-03 22:55 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-30 21:00 [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown Stuart Summers
2022-06-30 21:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix NPD in PMU during driver teardown (rev2) Patchwork
2022-07-01  0:11 ` [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown Umesh Nerlige Ramappa
2022-07-01  8:37   ` Tvrtko Ursulin
2022-07-01 14:54     ` Summers, Stuart
2022-07-04  8:31       ` Tvrtko Ursulin
2022-07-12 21:03         ` Umesh Nerlige Ramappa
2022-07-19  9:00           ` Tvrtko Ursulin
2022-07-20  0:22             ` Umesh Nerlige Ramappa
2022-07-20  8:14               ` Tvrtko Ursulin
2022-07-20 20:07                 ` Umesh Nerlige Ramappa
2022-07-21  4:30                   ` Summers, Stuart
2022-07-21  7:43                     ` Tvrtko Ursulin
2022-08-03 22:54                       ` Summers, Stuart
2022-07-01 18:09     ` Umesh Nerlige Ramappa
2022-07-01 13:54 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix NPD in PMU during driver teardown (rev2) Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2022-07-01 16:15 [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown Stuart Summers
2022-06-30 22:45 Stuart Summers
2022-06-29 18:46 Stuart Summers
2022-06-30 10:29 ` Tvrtko Ursulin
2022-06-30 19:04   ` Summers, Stuart

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.