From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>,
intel-xe@lists.freedesktop.org
Cc: Matthew Brost <matthew.brost@intel.com>,
Michal Wajdeczko <michal.wajdeczko@intel.com>,
Matthew Auld <matthew.auld@intel.com>
Subject: Re: [PATCH v2 2/3] drm/xe/sa: Add lockdep annotations for SA manager swap_guard
Date: Fri, 06 Feb 2026 17:17:46 +0100 [thread overview]
Message-ID: <65de6e6accc8e4344d9d068523fe01a6ecc3cff0.camel@linux.intel.com> (raw)
In-Reply-To: <20260204164642.3509298-7-satyanarayana.k.v.p@intel.com>
Hi
On Wed, 2026-02-04 at 16:46 +0000, Satyanarayana K V P wrote:
> Annotate the SA manager init path to model taking swap_guard while
> under
> reclaim context. This helps lockdep catch potential circular
> dependencies
> between fs_reclaim and swap_guard in debug builds.
>
> Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> Suggested-by: Matthew Brost <matthew.brost@intel.com>
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
>
> ---
> V1 -> V2:
> - None.
> ---
> drivers/gpu/drm/xe/xe_sa.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_sa.c b/drivers/gpu/drm/xe/xe_sa.c
> index b738102575d4..5efbb5a09f77 100644
> --- a/drivers/gpu/drm/xe/xe_sa.c
> +++ b/drivers/gpu/drm/xe/xe_sa.c
> @@ -89,6 +89,12 @@ struct xe_sa_manager
> *__xe_sa_bo_manager_init(struct xe_tile *tile, u32 size,
> if (ret)
> return ERR_PTR(ret);
>
> + if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
> + fs_reclaim_acquire(GFP_KERNEL);
> + might_lock(&sa_manager->swap_guard);
> + fs_reclaim_release(GFP_KERNEL);
> + }
> +
> shadow = xe_managed_bo_create_pin_map(xe, tile, size,
> XE_BO_FLAG_VRAM_IF_DGFX(tile) |
> XE_BO_FLAG_GGTT |
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
In addition to this, a couple of comments to the code that is already
in the driver:
It would be beneficial for understanding if a document section was
added for the typical usage flow of the shadow buffer, something like
the below (hope I got this correct).
*) Clearly stating the use-case: That the whole buffer is bound to HW
and can execute at any time. The shadow buffer is part of a double
buffering scheme so that updates are visible to the hardware
atomically.
*) The flow:
-lock()
-Swap buffers: The buffers are identical. The buffer bound to hardware
becomes the shadow.
-Update the primary buffer.
-Flush the cpu buffer to primary on DGFX (BTW IIRC this was missing in
the code). -Point the HW to the primary buffer.
-sync the shadow to the primary.
-unlock()
In addition perhaps more lockdep asserts an also perhaps pin the lock
in swap buffers and unpin in sync to shadow so that if anybody releases
the lock in between you'd get a warning.
But this can be done as a follow-up, (beware the possibly missing cpu
buffer flush, though). I think it's worth spending some time on this.
Thanks,
Thomas
A.
next prev parent reply other threads:[~2026-02-06 16:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-04 16:46 [PATCH v2 0/3] Fix fs_reclaim deadlock caused by CCS save/restore Satyanarayana K V P
2026-02-04 16:46 ` [PATCH v2 1/3] drm/sa: Split drm_suballoc_new() into SA alloc and init helpers Satyanarayana K V P
2026-02-04 19:45 ` Matthew Brost
2026-02-06 12:34 ` Thomas Hellström
2026-02-06 15:27 ` Christian König
2026-02-04 16:46 ` [PATCH v2 2/3] drm/xe/sa: Add lockdep annotations for SA manager swap_guard Satyanarayana K V P
2026-02-04 19:11 ` Matthew Brost
2026-02-06 16:17 ` Thomas Hellström [this message]
2026-02-06 18:28 ` Matthew Brost
2026-02-09 9:09 ` Thomas Hellström
2026-02-09 17:07 ` Matthew Brost
2026-02-04 16:46 ` [PATCH v2 3/3] drm/xe/vf: Fix fs_reclaim warning with CCS save/restore BB allocation Satyanarayana K V P
2026-02-04 19:18 ` Matthew Brost
2026-02-06 12:49 ` Thomas Hellström
2026-02-05 2:49 ` ✓ CI.KUnit: success for Fix fs_reclaim deadlock caused by CCS save/restore (rev2) Patchwork
2026-02-05 3:24 ` ✓ Xe.CI.BAT: " Patchwork
2026-02-05 18:34 ` ✓ Xe.CI.FULL: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65de6e6accc8e4344d9d068523fe01a6ecc3cff0.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=satyanarayana.k.v.p@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