public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oded Gabbay <ogabbay@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Yuri Nudelman <ynudelman@habana.ai>
Subject: [PATCH 2/3] habanalabs: add topic to memory manager buffer
Date: Mon,  9 May 2022 11:22:17 +0300	[thread overview]
Message-ID: <20220509082218.956916-2-ogabbay@kernel.org> (raw)
In-Reply-To: <20220509082218.956916-1-ogabbay@kernel.org>

From: Yuri Nudelman <ynudelman@habana.ai>

Currently, buffers from multiple flows pass through the same infra.
This way, in logs, we are unable to distinguish between buffers that
came from separate flows.
To address this problem, add a "topic" to buffer behavior
descriptor - a string identifier that will be used to identify in logs
the flow this buffer relates to.

Signed-off-by: Yuri Nudelman <ynudelman@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
---
 .../misc/habanalabs/common/command_buffer.c   |  1 +
 drivers/misc/habanalabs/common/habanalabs.h   |  2 ++
 drivers/misc/habanalabs/common/memory.c       |  1 +
 drivers/misc/habanalabs/common/memory_mgr.c   | 23 +++++++++++--------
 4 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/drivers/misc/habanalabs/common/command_buffer.c b/drivers/misc/habanalabs/common/command_buffer.c
index fd9ef32ea6a0..1fac72c38c87 100644
--- a/drivers/misc/habanalabs/common/command_buffer.c
+++ b/drivers/misc/habanalabs/common/command_buffer.c
@@ -319,6 +319,7 @@ static int hl_cb_mmap(struct hl_mmap_mem_buf *buf,
 }
 
 static struct hl_mmap_mem_buf_behavior cb_behavior = {
+	.topic = "CB",
 	.mem_id = HL_MMAP_TYPE_CB,
 	.alloc = hl_cb_mmap_mem_alloc,
 	.release = hl_cb_mmap_mem_release,
diff --git a/drivers/misc/habanalabs/common/habanalabs.h b/drivers/misc/habanalabs/common/habanalabs.h
index 59150caa98a2..918e8a04acab 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -731,6 +731,7 @@ struct hl_mem_mgr {
 
 /**
  * struct hl_mmap_mem_buf_behavior - describes unified memory manager buffer behavior
+ * @topic: string identifier used for logging
  * @mem_id: memory type identifier, embedded in the handle and used to identify
  *          the memory type by handle.
  * @alloc: callback executed on buffer allocation, shall allocate the memory,
@@ -739,6 +740,7 @@ struct hl_mem_mgr {
  * @release: callback executed on release, must free the resources used by the buffer
  */
 struct hl_mmap_mem_buf_behavior {
+	const char *topic;
 	u64 mem_id;
 
 	int (*alloc)(struct hl_mmap_mem_buf *buf, gfp_t gfp, void *args);
diff --git a/drivers/misc/habanalabs/common/memory.c b/drivers/misc/habanalabs/common/memory.c
index e7a0c44c487d..ecf3c094242a 100644
--- a/drivers/misc/habanalabs/common/memory.c
+++ b/drivers/misc/habanalabs/common/memory.c
@@ -2141,6 +2141,7 @@ static int hl_ts_alloc_buf(struct hl_mmap_mem_buf *buf, gfp_t gfp, void *args)
 }
 
 static struct hl_mmap_mem_buf_behavior hl_ts_behavior = {
+	.topic = "TS",
 	.mem_id = HL_MMAP_TYPE_TS_BUFF,
 	.mmap = hl_ts_mmap,
 	.alloc = hl_ts_alloc_buf,
diff --git a/drivers/misc/habanalabs/common/memory_mgr.c b/drivers/misc/habanalabs/common/memory_mgr.c
index 9f3ab6cf25d3..0ddfebe3a9ef 100644
--- a/drivers/misc/habanalabs/common/memory_mgr.c
+++ b/drivers/misc/habanalabs/common/memory_mgr.c
@@ -162,7 +162,8 @@ hl_mmap_mem_buf_alloc(struct hl_mem_mgr *mmg,
 	spin_unlock(&mmg->lock);
 	if (rc < 0) {
 		dev_err(mmg->dev,
-			"Failed to allocate IDR for a new buffer, rc=%d\n", rc);
+			"%s: Failed to allocate IDR for a new buffer, rc=%d\n",
+			behavior->topic, rc);
 		goto free_buf;
 	}
 
@@ -173,8 +174,8 @@ hl_mmap_mem_buf_alloc(struct hl_mem_mgr *mmg,
 
 	rc = buf->behavior->alloc(buf, gfp, args);
 	if (rc) {
-		dev_err(mmg->dev, "Failure in buffer alloc callback %d\n",
-			rc);
+		dev_err(mmg->dev, "%s: Failure in buffer alloc callback %d\n",
+			behavior->topic, rc);
 		goto remove_idr;
 	}
 
@@ -253,8 +254,8 @@ int hl_mem_mgr_mmap(struct hl_mem_mgr *mmg, struct vm_area_struct *vma,
 	user_mem_size = vma->vm_end - vma->vm_start;
 	if (user_mem_size != ALIGN(buf->mappable_size, PAGE_SIZE)) {
 		dev_err(mmg->dev,
-			"Memory mmap failed, mmap VM size 0x%llx != 0x%llx allocated physical mem size\n",
-			user_mem_size, buf->mappable_size);
+			"%s: Memory mmap failed, mmap VM size 0x%llx != 0x%llx allocated physical mem size\n",
+			buf->behavior->topic, user_mem_size, buf->mappable_size);
 		rc = -EINVAL;
 		goto put_mem;
 	}
@@ -266,8 +267,8 @@ int hl_mem_mgr_mmap(struct hl_mem_mgr *mmg, struct vm_area_struct *vma,
 	if (!access_ok((void __user *)(uintptr_t)vma->vm_start,
 		       user_mem_size)) {
 #endif
-		dev_err(mmg->dev, "user pointer is invalid - 0x%lx\n",
-			vma->vm_start);
+		dev_err(mmg->dev, "%s: User pointer is invalid - 0x%lx\n",
+			buf->behavior->topic, vma->vm_start);
 
 		rc = -EINVAL;
 		goto put_mem;
@@ -275,7 +276,8 @@ int hl_mem_mgr_mmap(struct hl_mem_mgr *mmg, struct vm_area_struct *vma,
 
 	if (atomic_cmpxchg(&buf->mmap, 0, 1)) {
 		dev_err(mmg->dev,
-			"Memory mmap failed, already mmaped to user\n");
+			"%s, Memory mmap failed, already mmaped to user\n",
+			buf->behavior->topic);
 		rc = -EINVAL;
 		goto put_mem;
 	}
@@ -328,14 +330,17 @@ void hl_mem_mgr_fini(struct hl_mem_mgr *mmg)
 {
 	struct hl_mmap_mem_buf *buf;
 	struct idr *idp;
+	const char *topic;
 	u32 id;
 
 	idp = &mmg->handles;
 
 	idr_for_each_entry(idp, buf, id) {
+		topic = buf->behavior->topic;
 		if (hl_mmap_mem_buf_put(buf) != 1)
 			dev_err(mmg->dev,
-				"Buff handle %u for CTX is still alive\n", id);
+				"%s: Buff handle %u for CTX is still alive\n",
+				topic, id);
 	}
 
 	/* TODO: can it happen that some buffer is still in use at this point? */
-- 
2.25.1


  reply	other threads:[~2022-05-09  8:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-09  8:22 [PATCH 1/3] habanalabs: handle race in driver fini Oded Gabbay
2022-05-09  8:22 ` Oded Gabbay [this message]
2022-05-09  8:22 ` [PATCH 3/3] habanalabs: add support for notification via eventfd 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=20220509082218.956916-2-ogabbay@kernel.org \
    --to=ogabbay@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ynudelman@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