From: Chengyu Liu <lui2012qwq@gmail.com>
To: dri-devel@lists.freedesktop.org
Cc: koby.elbaz@intel.com, konstantin.sinyuk@intel.com,
ogabbay@kernel.org, Chengyu Liu <lui2012qwq@gmail.com>
Subject: [PATCH v2] accel/habanalabs: disable pending-reset work in hl_device_fini()
Date: Wed, 4 Nov 2026 17:51:59 +0800 [thread overview]
Message-ID: <20261104095159.6487-1-lui2012qwq@gmail.com> (raw)
In-Reply-To: <20261103163354.1599176-1-lui2012qwq@gmail.com>
hl_device_fini() uses flush_delayed_work() to drain
device_reset_work.reset_work, but a flush cannot stop the work from
being armed again afterwards, so the reset work can still fire while -
or after - the device is torn down.
Simply switching the flush to disable_delayed_work_sync() is not
enough: a reset retry sitting on its timer holds reset_info.in_reset,
and only the work itself clears it (via out_err once
device_fini_pending is set). Killing the work without running it
strands in_reset, and hl_device_fini() then waits for the full
HL_HARD_RESET_MAX_TIMEOUT and returns without tearing the device
down.
So keep the flush first: with device_fini_pending set, a pending
retry runs immediately and clears in_reset via out_err. Then, after
in_reset has been claimed for fini - so no new reset can be queued
and the reset thread does not re-arm - disable the work to guarantee
nothing is pending or running during the teardown.
Found by static analysis.
Signed-off-by: Chengyu Liu <lui2012qwq@gmail.com>
---
v2: keep the flush so a pending reset retry still runs and clears
in_reset (sashiko review); the disable now happens after in_reset
is claimed for fini, where no new reset can be queued and the
reset thread does not re-arm.
drivers/accel/habanalabs/common/device.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/accel/habanalabs/common/device.c b/drivers/accel/habanalabs/common/device.c
index 09b27bac3a31..c27c13e693d5 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -2527,6 +2527,13 @@ void hl_device_fini(struct hl_device *hdev)
}
}
+ /*
+ * in_reset is claimed now, so no new reset can be queued and the
+ * reset thread does not re-arm with device_fini_pending set; make
+ * sure no reset work is left pending or running during teardown.
+ */
+ disable_delayed_work_sync(&hdev->device_reset_work.reset_work);
+
cancel_delayed_work_sync(&hdev->device_release_watchdog_work.reset_work);
/* Disable PCI access from device F/W so it won't send us additional
--
2.25.1
next prev parent reply other threads:[~2026-11-06 9:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 16:33 [PATCH] accel/habanalabs: disable pending-reset work in hl_device_fini() Chengyu Liu
2026-11-04 9:07 ` sashiko-bot
2026-11-04 9:46 ` Chengyu Liu
2026-11-04 9:51 ` Chengyu Liu [this message]
2026-11-06 9:28 ` [PATCH v2] " sashiko-bot
2026-11-06 12:05 ` [PATCH v3] " Chengyu Liu
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=20261104095159.6487-1-lui2012qwq@gmail.com \
--to=lui2012qwq@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=koby.elbaz@intel.com \
--cc=konstantin.sinyuk@intel.com \
--cc=ogabbay@kernel.org \
/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.