From: Matthew Auld <matthew.auld@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: [Intel-xe] [PATCH v9 4/8] drm/xe: tweak lock ordering for freq_lock
Date: Tue, 23 May 2023 10:47:23 +0100 [thread overview]
Message-ID: <20230523094727.162266-4-matthew.auld@intel.com> (raw)
In-Reply-To: <20230523094727.162266-1-matthew.auld@intel.com>
Lockdep spits out:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&xe->mem_access.lock);
lock(&pc->freq_lock);
lock(&xe->mem_access.lock);
lock(&pc->freq_lock);
It looks like we already mostly take care to ensure that the mem_access
ref is taken outside of taking freq_lock, since that is also grabbed
from the runtime_pm callbacks, except for a couple of spots in
xe_guc_pc and guc_ct_send_recv(). But tt looks like all the callers are
already holding the mem_access.ref, so just switch over to use
guc_ct_send_locked().
v2:
- There are few more cases it seems.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
drivers/gpu/drm/xe/xe_guc_ct.c | 4 +++-
drivers/gpu/drm/xe/xe_guc_pc.c | 8 ++++++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
index 9dc906f2651a..7a8c9d6a03f3 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.c
+++ b/drivers/gpu/drm/xe/xe_guc_ct.c
@@ -689,7 +689,9 @@ static int guc_ct_send_recv(struct xe_guc_ct *ct, const u32 *action, u32 len,
retry:
g2h_fence_init(&g2h_fence, response_buffer);
retry_same_fence:
- ret = guc_ct_send(ct, action, len, 0, 0, &g2h_fence);
+ mutex_lock(&ct->lock);
+ ret = guc_ct_send_locked(ct, action, len, 0, 0, &g2h_fence);
+ mutex_unlock(&ct->lock);
if (unlikely(ret == -ENOMEM)) {
void *ptr;
diff --git a/drivers/gpu/drm/xe/xe_guc_pc.c b/drivers/gpu/drm/xe/xe_guc_pc.c
index e799faa1c6b8..3b56e57d29af 100644
--- a/drivers/gpu/drm/xe/xe_guc_pc.c
+++ b/drivers/gpu/drm/xe/xe_guc_pc.c
@@ -225,7 +225,9 @@ static int pc_action_set_param(struct xe_guc_pc *pc, u8 id, u32 value)
if (wait_for_pc_state(pc, SLPC_GLOBAL_STATE_RUNNING))
return -EAGAIN;
- ret = xe_guc_ct_send(ct, action, ARRAY_SIZE(action), 0, 0);
+ mutex_lock(&ct->lock);
+ ret = xe_guc_ct_send_locked(ct, action, ARRAY_SIZE(action), 0, 0);
+ mutex_unlock(&ct->lock);
if (ret)
drm_err(&pc_to_xe(pc)->drm, "GuC PC set param failed: %pe",
ERR_PTR(ret));
@@ -242,7 +244,9 @@ static int pc_action_setup_gucrc(struct xe_guc_pc *pc, u32 mode)
};
int ret;
- ret = xe_guc_ct_send(ct, action, ARRAY_SIZE(action), 0, 0);
+ mutex_lock(&ct->lock);
+ ret = xe_guc_ct_send_locked(ct, action, ARRAY_SIZE(action), 0, 0);
+ mutex_unlock(&ct->lock);
if (ret)
drm_err(&pc_to_xe(pc)->drm, "GuC RC enable failed: %pe",
ERR_PTR(ret));
--
2.40.1
next prev parent reply other threads:[~2023-05-23 9:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-23 9:47 [Intel-xe] [PATCH v9 1/8] Revert "drm/xe: Use atomic instead of mutex for xe_device_mem_access_ongoing" Matthew Auld
2023-05-23 9:47 ` [Intel-xe] [PATCH v9 2/8] drm/xe: don't allocate under ct->lock Matthew Auld
2023-05-23 9:47 ` [Intel-xe] [PATCH v9 3/8] drm/xe: keep pulling mem_access_get further back Matthew Auld
2023-05-23 9:47 ` Matthew Auld [this message]
2023-05-23 13:07 ` [Intel-xe] [PATCH v9 4/8] drm/xe: tweak lock ordering for freq_lock Rodrigo Vivi
2023-05-23 13:13 ` Matthew Auld
2023-05-23 9:47 ` [Intel-xe] [PATCH v9 5/8] drm/xe/ggtt: prime ggtt->lock against FS_RECLAIM Matthew Auld
2023-05-23 9:47 ` [Intel-xe] [PATCH v9 6/8] drm/xe/ct: drop mem_access_get from g2h_worker_func() Matthew Auld
2023-05-23 13:04 ` Rodrigo Vivi
2023-05-23 13:10 ` Matthew Auld
2023-05-23 9:47 ` [Intel-xe] [PATCH v9 7/8] drm/xe: fix xe_device_mem_access_get() races Matthew Auld
2023-05-23 9:47 ` [Intel-xe] [PATCH v9 8/8] drm/xe: Use atomic for mem_access.ref Matthew Auld
2023-05-23 9:49 ` [Intel-xe] ✓ CI.Patch_applied: success for series starting with [v9,1/8] Revert "drm/xe: Use atomic instead of mutex for xe_device_mem_access_ongoing" Patchwork
2023-05-23 9:51 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-05-23 9:55 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-05-23 10:19 ` [Intel-xe] ○ CI.BAT: info " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230523094727.162266-4-matthew.auld@intel.com \
--to=matthew.auld@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=rodrigo.vivi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox