diff options
| author | Tomasz Lis <tomasz.lis@intel.com> | 2026-02-26 22:26:59 +0100 |
|---|---|---|
| committer | Michal Wajdeczko <michal.wajdeczko@intel.com> | 2026-02-27 18:02:04 +0100 |
| commit | ec172c7befc4a48ea7d6afe6f0fa23c533222233 (patch) | |
| tree | 8528e331ac4b2c2a257fcf9fb50dc3f99d2cc2fa /tools/perf/scripts/python/bin/stackcollapse-record | |
| parent | 393e5fea6f7d7054abc2c3d97a4cfe8306cd6079 (diff) | |
drm/xe: Wrappers for setting and getting LRC references
There is a small but non-zero chance that VF post migration fixups
are running on an exec queue during teardown. The chances are
decreased by starting the teardown by releasing guc_id, but remain
non-zero. On the other hand the sync between fixups and EQ creation
(wait_valid_ggtt) drastically increases the chance for such parallel
teardown if queue creation error path is entered (err_lrc label).
The exec queue itself is not going to cause an issue, but LRCs have
a small chance of getting freed during the fixups.
Creating a setter and a getter makes it easier to protect the fixup
operations with a lock. For other driver activities, the original
access method (without any protection) can still be used.
v2: Separate lock, only for LRCs. Kerneldoc fixes. Subject tag fix.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patch.msgid.link/20260226212701.2937065-3-tomasz.lis@intel.com
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-record')
0 files changed, 0 insertions, 0 deletions
