From: Raag Jadav <raag.jadav@intel.com>
To: "Tauro, Riana" <riana.tauro@intel.com>
Cc: intel-xe@lists.freedesktop.org, anshuman.gupta@intel.com,
rodrigo.vivi@intel.com, aravind.iddamsetty@linux.intel.com,
mallesh.koujalagi@intel.com, badal.nilawar@intel.com
Subject: Re: [PATCH v4 3/8] drm/xe/survivability: Guard runtime survivability enable against unbind
Date: Wed, 11 Nov 2026 08:09:16 +0100 [thread overview]
Message-ID: <avQUnHig9Ign-njH@black.igk.intel.com> (raw)
In-Reply-To: <524ae4f5-d484-4af4-a7ac-68bdaef970c5@intel.com>
On Wed, Nov 11, 2026 at 11:20:02AM +0530, Tauro, Riana wrote:
> On 11-11-2026 11:09, Raag Jadav wrote:
> > On Wed, Nov 11, 2026 at 10:13:44AM +0530, Tauro, Riana wrote:
> > > On 10-11-2026 18:21, Raag Jadav wrote:
> > > > On Fri, Nov 06, 2026 at 12:49:48PM +0530, Riana Tauro wrote:
> > > > > Runtime surivability mode creates sysfs and declares the device as
> > > > > wedged in a worker thread. This can race with unbind.
> > > > >
> > > > > During unbind, devres actions such as disabling the worker run as part of
> > > > > teardown. A runtime survivability enable that is still in flight or gets
> > > > > scheduled in that window can create the survivability sysfs entries while
> > > > > the device is being removed. This is incorrect, as runtime survivability mode
> > > > > must not be entered once during devres teardown.
> > > > >
> > > > > Use the DRM device enter/exit protection so that the enable path
> > > > > synchronizes with device unplug and returns early if the device is
> > > > > already being unbound.
> > > > I'm a bit lost here. Doesn't disable_work_sync() already guarantee this?
> > > If the worker is already queued and there is a unbind in progress. The
> > > disable work sync from devm
> > > action waits for the worker to complete. This causes the device to enter
> > > survivability mode during unbind
> > > which is not intended.
> > Wouldn't the survivability stuff still land on devres and get cleaned
> > up anyway?
>
> devres_release_all running as part of unbind copies all the devres nodes
> into a todo list and then
> releases them. If during release, we add a new devres that will not be
> cleared during unbind
> which can cause stale sysfs.
Hm, I thought all the devm actions are protected by devres_lock but
you're right.
A more robust fix would be to disable all the workers in ->remove()
callback itself and avoid such races to begin with, but I'll leave it
upto you.
Raag
next prev parent reply other threads:[~2026-11-11 7:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 7:19 [PATCH v4 0/8] Handle non-fatal errors routed via IRQ Riana Tauro
2026-11-06 7:19 ` [PATCH v4 1/8] drm/xe/hw_error: Reuse CSC worker for generic error handling Riana Tauro
2026-11-06 7:19 ` [PATCH v4 2/8] drm/xe/hw_error: Initialize hw_error_work per tile Riana Tauro
2026-11-10 5:48 ` Mallesh, Koujalagi
2026-11-10 12:40 ` Raag Jadav
2026-11-11 4:45 ` Tauro, Riana
2026-11-11 5:40 ` Raag Jadav
2026-11-11 5:51 ` Tauro, Riana
2026-11-06 7:19 ` [PATCH v4 3/8] drm/xe/survivability: Guard runtime survivability enable against unbind Riana Tauro
2026-11-10 6:19 ` Mallesh, Koujalagi
2026-11-10 12:51 ` Raag Jadav
2026-11-11 4:43 ` Tauro, Riana
2026-11-11 5:39 ` Raag Jadav
2026-11-11 5:50 ` Tauro, Riana
2026-11-11 7:09 ` Raag Jadav [this message]
2026-11-11 7:17 ` Tauro, Riana
2026-11-06 7:19 ` [PATCH v4 4/8] drm/xe/ras: Treat non-fatal PCIe errors as recovered Riana Tauro
2026-11-06 7:19 ` [PATCH v4 5/8] drm/xe/pci: Add upstream switch port lookup helper Riana Tauro
2026-11-06 7:19 ` [PATCH v4 6/8] drm/xe/xe_ras: Add a flag for uncorrectable internal error Riana Tauro
2026-11-10 13:07 ` Raag Jadav
2026-11-11 4:47 ` Tauro, Riana
2026-11-06 7:19 ` [PATCH v4 7/8] drm/xe: Add support for wa_14028434957 Riana Tauro
2026-11-10 6:41 ` Mallesh, Koujalagi
2026-11-10 13:18 ` Raag Jadav
2026-11-11 4:50 ` Tauro, Riana
2026-11-11 6:15 ` Raag Jadav
2026-11-11 6:22 ` Tauro, Riana
2026-11-06 7:19 ` [PATCH v4 8/8] drm/xe/xe_ras: Skip double-bit ECC page offlining on AER path Riana Tauro
2026-11-06 7:27 ` ✗ CI.checkpatch: warning for Handle non-fatal errors routed via IRQ (rev4) Patchwork
2026-11-06 7:29 ` ✓ CI.KUnit: success " Patchwork
2026-11-06 8:13 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-07 7:38 ` ✗ Xe.CI.FULL: failure " 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=avQUnHig9Ign-njH@black.igk.intel.com \
--to=raag.jadav@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=aravind.iddamsetty@linux.intel.com \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=mallesh.koujalagi@intel.com \
--cc=riana.tauro@intel.com \
--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 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.