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 16/20] habanalabs: reset device if still in use when released
Date: Thu, 17 Nov 2022 18:19:47 +0200	[thread overview]
Message-ID: <20221117161951.845454-16-ogabbay@kernel.org> (raw)
In-Reply-To: <20221117161951.845454-1-ogabbay@kernel.org>

From: Tomer Tayar <ttayar@habana.ai>

If the device file is released while a context is still held, it won't
be possible to reopen it until the context is eventually released.
If that doesn't happen, only a device reset will revert it back to an
operational state, i.e. need to wait for a CS timeout or an error, or to
wait for an external intervention of injecting a reset via sysfs.

At this stage, after the device was released by user, context is held
either because of CS which were left running on the device and are not
relevant anymore, or due to missing cleanup steps from user side.

All of this is in any case handled in the device reset flow, so initiate
the reset at this point instead of waiting for it.

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

diff --git a/drivers/misc/habanalabs/common/device.c b/drivers/misc/habanalabs/common/device.c
index 708db0f48ee0..49640c8ca910 100644
--- a/drivers/misc/habanalabs/common/device.c
+++ b/drivers/misc/habanalabs/common/device.c
@@ -504,9 +504,10 @@ static int hl_device_release(struct inode *inode, struct file *filp)
 
 	hdev->compute_ctx_in_release = 1;
 
-	if (!hl_hpriv_put(hpriv))
-		dev_notice(hdev->dev,
-			"User process closed FD but device still in use\n");
+	if (!hl_hpriv_put(hpriv)) {
+		dev_notice(hdev->dev, "User process closed FD but device still in use\n");
+		hl_device_reset(hdev, HL_DRV_RESET_HARD);
+	}
 
 	hdev->last_open_session_duration_jif =
 		jiffies - hdev->last_successful_open_jif;
-- 
2.25.1


  parent reply	other threads:[~2022-11-17 16:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-17 16:19 [PATCH 01/20] habanalabs/gaudi2: add PCI revision 2 support Oded Gabbay
2022-11-17 16:19 ` [PATCH 02/20] habanalabs/gaudi: add razwi notify event Oded Gabbay
2022-11-17 16:19 ` [PATCH 03/20] habanalabs: use single threaded WQ for event handling Oded Gabbay
2022-11-17 16:19 ` [PATCH 04/20] habanalabs/gaudi: add page fault notify event Oded Gabbay
2022-11-17 16:19 ` [PATCH 05/20] habanalabs/gaudi2: implement fp32 not supported event Oded Gabbay
2022-11-17 16:19 ` [PATCH 06/20] habanalabs/gaudi2: add razwi notify event Oded Gabbay
2022-11-17 16:19 ` [PATCH 07/20] habanalabs: fix firmware descriptor copy operation Oded Gabbay
2022-11-17 16:19 ` [PATCH 08/20] habanalabs: skip events info ioctl if not supported Oded Gabbay
2022-11-17 16:19 ` [PATCH 09/20] habanalabs/gaudi2: classify power/thermal events as info Oded Gabbay
2022-11-17 16:19 ` [PATCH 10/20] habanalabs/gaudi2: add page fault notify event Oded Gabbay
2022-11-17 16:19 ` [PATCH 11/20] habanalabs: fix print for out-of-sync and pkt-failure events Oded Gabbay
2022-11-17 16:19 ` [PATCH 12/20] habanalabs/gaudi: fix print for firmware-alive event Oded Gabbay
2022-11-17 16:19 ` [PATCH 13/20] habanalabs/gaudi2: remove redundant firmware version check Oded Gabbay
2022-11-17 16:19 ` [PATCH 14/20] habanalabs/gaudi2: don't enable entries in the MSIX_GW table Oded Gabbay
2022-11-17 16:19 ` [PATCH 15/20] habanalabs/gaudi2: return to reset upon SM SEI BRESP error Oded Gabbay
2022-11-17 16:19 ` Oded Gabbay [this message]
2022-11-17 16:19 ` [PATCH 17/20] habanalabs: check schedule_hard_reset correctly Oded Gabbay
2022-11-17 16:19 ` [PATCH 18/20] habanalabs: extend process wait timeout in device fine Oded Gabbay
2022-11-17 16:19 ` [PATCH 19/20] habanalabs/gaudi2: change memory scrub mechanism Oded Gabbay
2022-11-17 16:19 ` [PATCH 20/20] habanalabs: increase the size of busy engines mask 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=20221117161951.845454-16-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®