mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Oded Gabbay <ogabbay@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Tomer Tayar <ttayar@habana.ai>
Subject: [PATCH 04/26] habanalabs: abort waiting user threads upon error
Date: Thu,  8 Dec 2022 17:13:28 +0200	[thread overview]
Message-ID: <20221208151350.1833823-4-ogabbay@kernel.org> (raw)
In-Reply-To: <20221208151350.1833823-1-ogabbay@kernel.org>

From: Tomer Tayar <ttayar@habana.ai>

User should close the FD when being notified about an error, after
which a device reset takes place.

However, if the user has pending threads that wait for completions,
the device release won't be called and eventually the watchdog timeout
will expire, leading to hard reset and killing the user process.

To avoid it, abort such waiting threads right after the error
notification, and block following waiting operations.

Signed-off-by: Tomer Tayar <ttayar@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
---
 .../habanalabs/common/command_submission.c    | 28 +++++++++++++++++--
 drivers/misc/habanalabs/common/device.c       |  2 ++
 drivers/misc/habanalabs/common/habanalabs.h   |  1 +
 3 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/habanalabs/common/command_submission.c b/drivers/misc/habanalabs/common/command_submission.c
index ea0e5101c10e..cf3b82efc65c 100644
--- a/drivers/misc/habanalabs/common/command_submission.c
+++ b/drivers/misc/habanalabs/common/command_submission.c
@@ -1117,6 +1117,27 @@ void hl_release_pending_user_interrupts(struct hl_device *hdev)
 	wake_pending_user_interrupt_threads(interrupt);
 }
 
+static void force_complete_cs(struct hl_device *hdev)
+{
+	struct hl_cs *cs;
+
+	spin_lock(&hdev->cs_mirror_lock);
+
+	list_for_each_entry(cs, &hdev->cs_mirror_list, mirror_node) {
+		cs->fence->error = -EIO;
+		complete_all(&cs->fence->completion);
+	}
+
+	spin_unlock(&hdev->cs_mirror_lock);
+}
+
+void hl_abort_waitings_for_completion(struct hl_device *hdev)
+{
+	force_complete_cs(hdev);
+	force_complete_multi_cs(hdev);
+	hl_release_pending_user_interrupts(hdev);
+}
+
 static void job_wq_completion(struct work_struct *work)
 {
 	struct hl_cs_job *job = container_of(work, struct hl_cs_job,
@@ -3489,14 +3510,15 @@ static int hl_interrupt_wait_ioctl(struct hl_fpriv *hpriv, void *data)
 
 int hl_wait_ioctl(struct hl_fpriv *hpriv, void *data)
 {
+	struct hl_device *hdev = hpriv->hdev;
 	union hl_wait_cs_args *args = data;
 	u32 flags = args->in.flags;
 	int rc;
 
-	/* If the device is not operational, no point in waiting for any command submission or
-	 * user interrupt
+	/* If the device is not operational, or if an error has happened and user should release the
+	 * device, there is no point in waiting for any command submission or user interrupt.
 	 */
-	if (!hl_device_operational(hpriv->hdev, NULL))
+	if (!hl_device_operational(hpriv->hdev, NULL) || hdev->reset_info.watchdog_active)
 		return -EBUSY;
 
 	if (flags & HL_WAIT_CS_FLAGS_INTERRUPT)
diff --git a/drivers/misc/habanalabs/common/device.c b/drivers/misc/habanalabs/common/device.c
index 1453f2ec72d9..92721111b652 100644
--- a/drivers/misc/habanalabs/common/device.c
+++ b/drivers/misc/habanalabs/common/device.c
@@ -1865,6 +1865,8 @@ int hl_device_cond_reset(struct hl_device *hdev, u32 flags, u64 event_mask)
 
 	hl_ctx_put(ctx);
 
+	hl_abort_waitings_for_completion(hdev);
+
 	return 0;
 
 device_reset:
diff --git a/drivers/misc/habanalabs/common/habanalabs.h b/drivers/misc/habanalabs/common/habanalabs.h
index 9e42d0e9ce33..7fb45610ad0c 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -3791,6 +3791,7 @@ void hl_dec_fini(struct hl_device *hdev);
 void hl_dec_ctx_fini(struct hl_ctx *ctx);
 
 void hl_release_pending_user_interrupts(struct hl_device *hdev);
+void hl_abort_waitings_for_completion(struct hl_device *hdev);
 int hl_cs_signal_sob_wraparound_handler(struct hl_device *hdev, u32 q_idx,
 			struct hl_hw_sob **hw_sob, u32 count, bool encaps_sig);
 
-- 
2.25.1


  parent reply	other threads:[~2022-12-08 15:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-08 15:13 [PATCH 01/26] habanalabs/gaudi2: fix BMON 3rd address range Oded Gabbay
2022-12-08 15:13 ` [PATCH 02/26] habanalabs: read binning info from preboot Oded Gabbay
2022-12-08 15:13 ` [PATCH 03/26] habanalabs: remove releasing of user threads from device release Oded Gabbay
2022-12-08 15:13 ` Oded Gabbay [this message]
2022-12-08 15:13 ` [PATCH 05/26] habanalabs: don't notify user about clk throttling due to power Oded Gabbay
2022-12-08 15:13 ` [PATCH 06/26] habanalabs: don't allow user to destroy CB handle more than once Oded Gabbay
2022-12-08 15:13 ` [PATCH 07/26] habanalabs: use dev_dbg() when hl_mmap_mem_buf_get() fails Oded Gabbay
2022-12-08 15:13 ` [PATCH 08/26] habanalabs: make set_dram_properties an ASIC function Oded Gabbay
2022-12-08 15:13 ` [PATCH 09/26] habanalabs: fix double assignment in MMU V1 Oded Gabbay
2022-12-08 15:13 ` [PATCH 10/26] habanalabs: update DRAM props according to preboot data Oded Gabbay
2022-12-08 15:13 ` [PATCH 11/26] habanalabs/gaudi2: count interrupt causes Oded Gabbay
2022-12-08 15:13 ` [PATCH 12/26] habanalabs/gaudi2: remove duplicated event prints Oded Gabbay
2022-12-08 15:13 ` [PATCH 13/26] habanalabs: adjacent timestamps should be more accurate Oded Gabbay
2022-12-08 15:13 ` [PATCH 14/26] habanalabs: skip device idle check in hpriv_release if in reset Oded Gabbay
2022-12-08 15:13 ` [PATCH 15/26] habanalabs/gaudi2: support abrupt device reset event Oded Gabbay
2022-12-08 15:13 ` [PATCH 16/26] habanalabs: define traces for COMMS protocol Oded Gabbay
2022-12-08 15:13 ` [PATCH 17/26] habanalabs: trace " Oded Gabbay
2022-12-08 15:13 ` [PATCH 18/26] habanalabs: set log level for descriptor validation to debug Oded Gabbay
2022-12-08 15:13 ` [PATCH 19/26] habanalabs: remove support to export dmabuf from handle Oded Gabbay
2022-12-08 15:13 ` [PATCH 20/26] habanalabs: helper function to validate export params Oded Gabbay
2022-12-08 15:13 ` [PATCH 21/26] habanalabs: modify export dmabuf API Oded Gabbay
2022-12-08 15:13 ` [PATCH 22/26] habanalabs: fix dmabuf to export only required size Oded Gabbay
2022-12-08 15:13 ` [PATCH 23/26] habanalabs: fix handling of wait CS for interrupting signals Oded Gabbay
2022-12-08 15:13 ` [PATCH 24/26] habanalabs: put fences in case of unexpected wait status Oded Gabbay
2022-12-08 15:13 ` [PATCH 25/26] habanalabs/gaudi2: wait for preboot ready if HW state is dirty Oded Gabbay
2022-12-08 15:13 ` [PATCH 26/26] habanalabs: fix wrong variable type used for vzalloc Oded Gabbay

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=20221208151350.1833823-4-ogabbay@kernel.org \
    --to=ogabbay@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ttayar@habana.ai \
    /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

all inboxes | Powered by JetHome®