All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Child <nnac123@linux.ibm.com>
To: netdev@vger.kernel.org
Cc: haren@linux.ibm.com, ricklind@us.ibm.com, danymadden@us.ibm.com,
	tlfalcon@linux.ibm.com, bjking1@linux.ibm.com,
	Nick Child <nnac123@linux.ibm.com>,
	Simon Horman <horms@kernel.org>
Subject: [PATCH net v2 3/5] ibmvnic: Handle DMA unmapping of login buffs in release functions
Date: Wed,  9 Aug 2023 17:10:36 -0500	[thread overview]
Message-ID: <20230809221038.51296-3-nnac123@linux.ibm.com> (raw)
In-Reply-To: <20230809221038.51296-1-nnac123@linux.ibm.com>

Rather than leaving the DMA unmapping of the login buffers to the
login response handler, move this work into the login release functions.
Previously, these functions were only used for freeing the allocated
buffers. This could lead to issues if there are more than one
outstanding login buffer requests, which is possible if a login request
times out.

If a login request times out, then there is another call to send login.
The send login function makes a call to the login buffer release
function. In the past, this freed the buffers but did not DMA unmap.
Therefore, the VIOS could still write to the old login (now freed)
buffer. It is for this reason that it is a good idea to leave the DMA
unmap call to the login buffers release function.

Since the login buffer release functions now handle DMA unmapping,
remove the duplicate DMA unmapping in handle_login_rsp().

Fixes: dff515a3e71d ("ibmvnic: Harden device login requests")
Signed-off-by: Nick Child <nnac123@linux.ibm.com>
Reviewed-by: Simon Horman <horms@kernel.org>
---
 drivers/net/ethernet/ibm/ibmvnic.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 668c67556190..77b0a744fa88 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1588,12 +1588,22 @@ static int ibmvnic_login(struct net_device *netdev)
 
 static void release_login_buffer(struct ibmvnic_adapter *adapter)
 {
+	if (!adapter->login_buf)
+		return;
+
+	dma_unmap_single(&adapter->vdev->dev, adapter->login_buf_token,
+			 adapter->login_buf_sz, DMA_TO_DEVICE);
 	kfree(adapter->login_buf);
 	adapter->login_buf = NULL;
 }
 
 static void release_login_rsp_buffer(struct ibmvnic_adapter *adapter)
 {
+	if (!adapter->login_rsp_buf)
+		return;
+
+	dma_unmap_single(&adapter->vdev->dev, adapter->login_rsp_buf_token,
+			 adapter->login_rsp_buf_sz, DMA_FROM_DEVICE);
 	kfree(adapter->login_rsp_buf);
 	adapter->login_rsp_buf = NULL;
 }
@@ -5411,11 +5421,6 @@ static int handle_login_rsp(union ibmvnic_crq *login_rsp_crq,
 	}
 	adapter->login_pending = false;
 
-	dma_unmap_single(dev, adapter->login_buf_token, adapter->login_buf_sz,
-			 DMA_TO_DEVICE);
-	dma_unmap_single(dev, adapter->login_rsp_buf_token,
-			 adapter->login_rsp_buf_sz, DMA_FROM_DEVICE);
-
 	/* If the number of queues requested can't be allocated by the
 	 * server, the login response will return with code 1. We will need
 	 * to resend the login buffer with fewer queues requested.
-- 
2.39.3


  parent reply	other threads:[~2023-08-09 22:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-09 22:10 [PATCH net v2 1/5] ibmvnic: Enforce stronger sanity checks on login response Nick Child
2023-08-09 22:10 ` [PATCH net v2 2/5] ibmvnic: Unmap DMA login rsp buffer on send login fail Nick Child
2023-08-09 22:10 ` Nick Child [this message]
2023-08-09 22:10 ` [PATCH net v2 4/5] ibmvnic: Do partial reset on login failure Nick Child
2023-08-09 22:10 ` [PATCH net v2 5/5] ibmvnic: Ensure login failure recovery is safe from other resets Nick Child
2023-08-10 17:50 ` [PATCH net v2 1/5] ibmvnic: Enforce stronger sanity checks on login response patchwork-bot+netdevbpf

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=20230809221038.51296-3-nnac123@linux.ibm.com \
    --to=nnac123@linux.ibm.com \
    --cc=bjking1@linux.ibm.com \
    --cc=danymadden@us.ibm.com \
    --cc=haren@linux.ibm.com \
    --cc=horms@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ricklind@us.ibm.com \
    --cc=tlfalcon@linux.ibm.com \
    /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.