All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oded Gabbay <ogabbay@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Dani Liberman <dliberman@habana.ai>
Subject: [PATCH 05/12] habanalabs: fix race condition in multi CS completion
Date: Sun, 28 Nov 2021 21:34:28 +0200	[thread overview]
Message-ID: <20211128193435.266534-5-ogabbay@kernel.org> (raw)
In-Reply-To: <20211128193435.266534-1-ogabbay@kernel.org>

From: Dani Liberman <dliberman@habana.ai>

Race example scenario:
1. User have 2 threads that waits on multi CS:
   - thread_0 waits on QID 0 and uses multi CS context 0.
   - thread_1 waits on QID 1 and uses multi CS context 1.
2. thread_1 got completion and release multi CS context 1.
3. CS related to multi CS of thread_0 starts executing
   complete_multi_cs function, the first iteration of the loop
   completes the multi CS of thread_0, hence multi CS context 0
   is released.
4. thread_1 waits on QID 1 and uses multi CS context 0.
5. thread_0 waits on QID 0 and uses multi CS context 1.
6. The second iterattion of the loop (from step 3) starts, which
   means, start checking multi CS context 1:
   - multi CS contetxt is being used by thread_0 waiting on QID 0.
   - The fence of the CS (still CS from step 3) has QID map the same
     as the multi CS context 1.
   - multi CS context 1 (thread_0) gets completion on CS that triggered
     already thread_0 (with multi CS context 0) and is no longer
     being waited on.

Fixed by exiting the loop in complete_multi_cs after getting completion

Signed-off-by: Dani Liberman <dliberman@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
---
 drivers/misc/habanalabs/common/command_submission.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/misc/habanalabs/common/command_submission.c b/drivers/misc/habanalabs/common/command_submission.c
index c1fd4ba14c60..4e893364a3cc 100644
--- a/drivers/misc/habanalabs/common/command_submission.c
+++ b/drivers/misc/habanalabs/common/command_submission.c
@@ -545,6 +545,13 @@ static void complete_multi_cs(struct hl_device *hdev, struct hl_cs *cs)
 			 * mcs fences.
 			 */
 			fence->mcs_handling_done = true;
+			/*
+			 * Since CS (and its related fence) can be associated with only one
+			 * multi CS context, once it triggered multi CS completion no need to
+			 * continue checking other multi CS contexts.
+			 */
+			spin_unlock(&mcs_compl->lock);
+			break;
 		}
 
 		spin_unlock(&mcs_compl->lock);
-- 
2.25.1


  parent reply	other threads:[~2021-11-28 19:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-28 19:34 [PATCH 01/12] habanalabs: fix soft reset accounting Oded Gabbay
2021-11-28 19:34 ` [PATCH 02/12] habanalabs: rename late init after reset function Oded Gabbay
2021-11-28 19:34 ` [PATCH 03/12] habanalabs/gaudi: return EPERM on non hard-reset Oded Gabbay
2021-11-28 19:34 ` [PATCH 04/12] habanalabs: move device boot warnings to the correct location Oded Gabbay
2021-11-28 19:34 ` Oded Gabbay [this message]
2021-11-28 19:34 ` [PATCH 06/12] habanalabs: add more info ioctls support during reset Oded Gabbay
2021-11-28 19:34 ` [PATCH 07/12] habanalabs: add power information type to POWER_GET packet Oded Gabbay
2021-11-28 19:34 ` [PATCH 08/12] habanalabs: change misleading IRQ warning during reset Oded Gabbay
2021-11-28 19:34 ` [PATCH 09/12] habanalabs: handle events during soft-reset Oded Gabbay
2021-11-28 19:34 ` [PATCH 10/12] habanalabs: skip read fw errors if dynamic descriptor invalid Oded Gabbay
2021-11-28 19:34 ` [PATCH 11/12] habanalabs: add SOB information to signal submission uAPI Oded Gabbay
2021-11-28 19:34 ` [PATCH 12/12] habanalabs: enable access to info ioctl during hard reset 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=20211128193435.266534-5-ogabbay@kernel.org \
    --to=ogabbay@kernel.org \
    --cc=dliberman@habana.ai \
    --cc=linux-kernel@vger.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.