diff mbox series

[SRU,Bionic,Xenial,1/1] vmxnet3: Remove buf_info from device accessible structures

Message ID 20210319192300.10231-1-doshir@vmware.com
State New
Headers show
Series Fixes for LP:1914143 | expand

Commit Message

Ronak Doshi March 19, 2021, 7:23 p.m. UTC 
From: Ronak Doshi <doshir at vmware.com>

BugLink: http://bugs.launchpad.net/bugs/1914143

buf_info structures in RX & TX queues are private driver data that
do not need to be visible to the device.  Although there is physical
address and length in the queue descriptor that points to these
structures, their layout is not standardized, and device never looks
at them.

So lets allocate these structures in non-DMA-able memory, and fill
physical address as all-ones and length as zero in the queue
descriptor.

That should alleviate worries brought by Martin Radev in
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20210104/022829.html
that malicious vmxnet3 device could subvert SVM/TDX guarantees.

Signed-off-by: Petr Vandrovec <petr@vmware.com>
Signed-off-by: Ronak Doshi <doshir@vmware.com>
---
Changes in v2:
 - Use kcalloc_node()
 - Remove log for memory allocation failure
Changes in v3:
 - Do not pass __GFP_ZERO to kcalloc
Changes in v4:
 - Modified description to not have subject line
Changes in v5:
 - Remove unnecessary ifs
Changes in v6:
 - Fixed subject line
---
 drivers/net/vmxnet3/vmxnet3_drv.c | 46 +++++++++++++--------------------------
 drivers/net/vmxnet3/vmxnet3_int.h |  2 --
 2 files changed, 15 insertions(+), 33 deletions(-)

Comments

Stefan Bader March 22, 2021, 12:37 p.m. UTC | #1 
On 19.03.21 20:23, Ronak Doshi wrote:
> From: Ronak Doshi <doshir at vmware.com>
> 
> BugLink: http://bugs.launchpad.net/bugs/1914143
> 
> buf_info structures in RX & TX queues are private driver data that
> do not need to be visible to the device.  Although there is physical
> address and length in the queue descriptor that points to these
> structures, their layout is not standardized, and device never looks
> at them.
> 
> So lets allocate these structures in non-DMA-able memory, and fill
> physical address as all-ones and length as zero in the queue
> descriptor.
> 
> That should alleviate worries brought by Martin Radev in
> https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20210104/022829.html
> that malicious vmxnet3 device could subvert SVM/TDX guarantees.
> 
> Signed-off-by: Petr Vandrovec <petr@vmware.com>
> Signed-off-by: Ronak Doshi <doshir@vmware.com>
> ---

The bug asks for this to be included in all releases, Why restrict this to 
Xenial and Bionic only. Also the patch is upstream

commit de1da8bcf40564a2adada2d5d5426e05355f66e8
Author: Ronak Doshi <doshir@vmware.com>
Date:   Wed Jan 27 18:08:16 2021 -0800

     vmxnet3: Remove buf_info from device accessible structures

so this should be a cherry pick / backport submission. Finally the cover email 
and the patch were sent as individual emails and not as reply to the cover email 
which makes it had to keep things together.

-Stefan

> Changes in v2:
>   - Use kcalloc_node()
>   - Remove log for memory allocation failure
> Changes in v3:
>   - Do not pass __GFP_ZERO to kcalloc
> Changes in v4:
>   - Modified description to not have subject line
> Changes in v5:
>   - Remove unnecessary ifs
> Changes in v6:
>   - Fixed subject line
> ---
>   drivers/net/vmxnet3/vmxnet3_drv.c | 46 +++++++++++++--------------------------
>   drivers/net/vmxnet3/vmxnet3_int.h |  2 --
>   2 files changed, 15 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
> index 336504b7531d..6e87f1fc4874 100644
> --- a/drivers/net/vmxnet3/vmxnet3_drv.c
> +++ b/drivers/net/vmxnet3/vmxnet3_drv.c
> @@ -451,12 +451,8 @@ vmxnet3_tq_destroy(struct vmxnet3_tx_queue *tq,
>   				  tq->comp_ring.base, tq->comp_ring.basePA);
>   		tq->comp_ring.base = NULL;
>   	}
> -	if (tq->buf_info) {
> -		dma_free_coherent(&adapter->pdev->dev,
> -				  tq->tx_ring.size * sizeof(tq->buf_info[0]),
> -				  tq->buf_info, tq->buf_info_pa);
> -		tq->buf_info = NULL;
> -	}
> +	kfree(tq->buf_info);
> +	tq->buf_info = NULL;
>   }
>   
>   
> @@ -505,8 +501,6 @@ static int
>   vmxnet3_tq_create(struct vmxnet3_tx_queue *tq,
>   		  struct vmxnet3_adapter *adapter)
>   {
> -	size_t sz;
> -
>   	BUG_ON(tq->tx_ring.base || tq->data_ring.base ||
>   	       tq->comp_ring.base || tq->buf_info);
>   
> @@ -534,9 +528,9 @@ vmxnet3_tq_create(struct vmxnet3_tx_queue *tq,
>   		goto err;
>   	}
>   
> -	sz = tq->tx_ring.size * sizeof(tq->buf_info[0]);
> -	tq->buf_info = dma_alloc_coherent(&adapter->pdev->dev, sz,
> -					  &tq->buf_info_pa, GFP_KERNEL);
> +	tq->buf_info = kcalloc_node(tq->tx_ring.size, sizeof(tq->buf_info[0]),
> +				    GFP_KERNEL,
> +				    dev_to_node(&adapter->pdev->dev));
>   	if (!tq->buf_info)
>   		goto err;
>   
> @@ -1737,13 +1731,9 @@ static void vmxnet3_rq_destroy(struct vmxnet3_rx_queue *rq,
>   		rq->comp_ring.base = NULL;
>   	}
>   
> -	if (rq->buf_info[0]) {
> -		size_t sz = sizeof(struct vmxnet3_rx_buf_info) *
> -			(rq->rx_ring[0].size + rq->rx_ring[1].size);
> -		dma_free_coherent(&adapter->pdev->dev, sz, rq->buf_info[0],
> -				  rq->buf_info_pa);
> -		rq->buf_info[0] = rq->buf_info[1] = NULL;
> -	}
> +	kfree(rq->buf_info[0]);
> +	rq->buf_info[0] = NULL;
> +	rq->buf_info[1] = NULL;
>   }
>   
>   static void
> @@ -1883,10 +1873,9 @@ vmxnet3_rq_create(struct vmxnet3_rx_queue *rq, struct vmxnet3_adapter *adapter)
>   		goto err;
>   	}
>   
> -	sz = sizeof(struct vmxnet3_rx_buf_info) * (rq->rx_ring[0].size +
> -						   rq->rx_ring[1].size);
> -	bi = dma_alloc_coherent(&adapter->pdev->dev, sz, &rq->buf_info_pa,
> -				GFP_KERNEL);
> +	bi = kcalloc_node(rq->rx_ring[0].size + rq->rx_ring[1].size,
> +			  sizeof(rq->buf_info[0][0]), GFP_KERNEL,
> +			  dev_to_node(&adapter->pdev->dev));
>   	if (!bi)
>   		goto err;
>   
> @@ -2522,14 +2511,12 @@ vmxnet3_setup_driver_shared(struct vmxnet3_adapter *adapter)
>   		tqc->txRingBasePA   = cpu_to_le64(tq->tx_ring.basePA);
>   		tqc->dataRingBasePA = cpu_to_le64(tq->data_ring.basePA);
>   		tqc->compRingBasePA = cpu_to_le64(tq->comp_ring.basePA);
> -		tqc->ddPA           = cpu_to_le64(tq->buf_info_pa);
> +		tqc->ddPA           = cpu_to_le64(~0ULL);
>   		tqc->txRingSize     = cpu_to_le32(tq->tx_ring.size);
>   		tqc->dataRingSize   = cpu_to_le32(tq->data_ring.size);
>   		tqc->txDataRingDescSize = cpu_to_le32(tq->txdata_desc_size);
>   		tqc->compRingSize   = cpu_to_le32(tq->comp_ring.size);
> -		tqc->ddLen          = cpu_to_le32(
> -					sizeof(struct vmxnet3_tx_buf_info) *
> -					tqc->txRingSize);
> +		tqc->ddLen          = cpu_to_le32(0);
>   		tqc->intrIdx        = tq->comp_ring.intr_idx;
>   	}
>   
> @@ -2541,14 +2528,11 @@ vmxnet3_setup_driver_shared(struct vmxnet3_adapter *adapter)
>   		rqc->rxRingBasePA[0] = cpu_to_le64(rq->rx_ring[0].basePA);
>   		rqc->rxRingBasePA[1] = cpu_to_le64(rq->rx_ring[1].basePA);
>   		rqc->compRingBasePA  = cpu_to_le64(rq->comp_ring.basePA);
> -		rqc->ddPA            = cpu_to_le64(rq->buf_info_pa);
> +		rqc->ddPA            = cpu_to_le64(~0ULL);
>   		rqc->rxRingSize[0]   = cpu_to_le32(rq->rx_ring[0].size);
>   		rqc->rxRingSize[1]   = cpu_to_le32(rq->rx_ring[1].size);
>   		rqc->compRingSize    = cpu_to_le32(rq->comp_ring.size);
> -		rqc->ddLen           = cpu_to_le32(
> -					sizeof(struct vmxnet3_rx_buf_info) *
> -					(rqc->rxRingSize[0] +
> -					 rqc->rxRingSize[1]));
> +		rqc->ddLen           = cpu_to_le32(0);
>   		rqc->intrIdx         = rq->comp_ring.intr_idx;
>   		if (VMXNET3_VERSION_GE_3(adapter)) {
>   			rqc->rxDataRingBasePA =
> diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
> index d958b92c9429..e910596b79cf 100644
> --- a/drivers/net/vmxnet3/vmxnet3_int.h
> +++ b/drivers/net/vmxnet3/vmxnet3_int.h
> @@ -240,7 +240,6 @@ struct vmxnet3_tx_queue {
>   	spinlock_t                      tx_lock;
>   	struct vmxnet3_cmd_ring         tx_ring;
>   	struct vmxnet3_tx_buf_info      *buf_info;
> -	dma_addr_t                       buf_info_pa;
>   	struct vmxnet3_tx_data_ring     data_ring;
>   	struct vmxnet3_comp_ring        comp_ring;
>   	struct Vmxnet3_TxQueueCtrl      *shared;
> @@ -298,7 +297,6 @@ struct vmxnet3_rx_queue {
>   	u32 qid2;           /* rqID in RCD for buffer from 2nd ring */
>   	u32 dataRingQid;    /* rqID in RCD for buffer from data ring */
>   	struct vmxnet3_rx_buf_info     *buf_info[2];
> -	dma_addr_t                      buf_info_pa;
>   	struct Vmxnet3_RxQueueCtrl            *shared;
>   	struct vmxnet3_rq_driver_stats  stats;
>   } __attribute__((__aligned__(SMP_CACHE_BYTES)));
>
Ronak Doshi March 22, 2021, 5:28 p.m. UTC | #2 
On 3/22/21, 5:38 AM, "Stefan Bader" <stefan.bader@canonical.com> wrote:

> The bug asks for this to be included in all releases, Why restrict this to 
> Xenial and Bionic only. Also the patch is upstream
>
>    commit de1da8bcf40564a2adada2d5d5426e05355f66e8
>    Author: Ronak Doshi <doshir@vmware.com>
>    Date:   Wed Jan 27 18:08:16 2021 -0800
>
>         vmxnet3: Remove buf_info from device accessible structures
>
>    so this should be a cherry pick / backport submission. Finally the cover email 
>    and the patch were sent as individual emails and not as reply to the cover email 
>    which makes it had to keep things together.
>
>    -Stefan

Hi Stefan,

I am not sure of the process here. I usually raise a bug and the patches are ported to the
kernels. This time I was asked to send the patch to this mailing list. Yes, the patch is upstream.
Could you apply the patch to appropriate kernels or let me know what the next steps should be?

Thanks,
Ronak
Stefan Bader March 23, 2021, 9:29 a.m. UTC | #3 
On 22.03.21 18:28, Ronak Doshi wrote:
> 
> On 3/22/21, 5:38 AM, "Stefan Bader" <stefan.bader@canonical.com> wrote:
> 
>> The bug asks for this to be included in all releases, Why restrict this to
>> Xenial and Bionic only. Also the patch is upstream
>>
>>     commit de1da8bcf40564a2adada2d5d5426e05355f66e8
>>     Author: Ronak Doshi <doshir@vmware.com>
>>     Date:   Wed Jan 27 18:08:16 2021 -0800
>>
>>          vmxnet3: Remove buf_info from device accessible structures
>>
>>     so this should be a cherry pick / backport submission. Finally the cover email
>>     and the patch were sent as individual emails and not as reply to the cover email
>>     which makes it had to keep things together.
>>
>>     -Stefan
> 
> Hi Stefan,
> 
> I am not sure of the process here. I usually raise a bug and the patches are ported to the
> kernels. This time I was asked to send the patch to this mailing list. Yes, the patch is upstream.
> Could you apply the patch to appropriate kernels or let me know what the next steps should be?

Hi Ronak,

there would be two options depending on urgency. If timing is less important and 
things are applicable for upstream stable kernels as well then getting things 
there will flow back into the Ubuntu kernels as well.

For direct submission, we need to consider it for every supported release 
(including the upcoming one). The patch format should be that of a cherry-pick 
-x (meaning to have a cherry picked from ...) line before the additional signed 
off by. It would be backported from if it does not apply cleanly. Additionally 
there should be a line

BugLink: https://bugs.launchpad.net/bugs/xxx

added (usually at the top). A patch needs to be sent only once for a set of 
kernels it applies. IOW if it cherry picks for all only once. When the 
format-patch is done with --cover-letter there will be a template cover email 
generated and if that and the patch are sent together in one git send-email step 
the patch will become a reply to the cover email. That part is because otherwise 
cover email and patch may float independently in the email reader's view and it 
becomes hard to link the two together.
To help getting a list of required series, you should be able to nominate the 
bug report for series which brings up a bullet list.

-Stefan

> 
> Thanks,
> Ronak
>      
> 
>
Krzysztof Kozlowski March 23, 2021, 11:45 a.m. UTC | #4 
On 23/03/2021 10:29, Stefan Bader wrote:
> On 22.03.21 18:28, Ronak Doshi wrote:
>>
>> On 3/22/21, 5:38 AM, "Stefan Bader" <stefan.bader@canonical.com> wrote:
>>
>>> The bug asks for this to be included in all releases, Why restrict this to
>>> Xenial and Bionic only. Also the patch is upstream
>>>
>>>     commit de1da8bcf40564a2adada2d5d5426e05355f66e8
>>>     Author: Ronak Doshi <doshir@vmware.com>
>>>     Date:   Wed Jan 27 18:08:16 2021 -0800
>>>
>>>          vmxnet3: Remove buf_info from device accessible structures
>>>
>>>     so this should be a cherry pick / backport submission. Finally the cover email
>>>     and the patch were sent as individual emails and not as reply to the cover email
>>>     which makes it had to keep things together.
>>>
>>>     -Stefan
>>
>> Hi Stefan,
>>
>> I am not sure of the process here. I usually raise a bug and the patches are ported to the
>> kernels. This time I was asked to send the patch to this mailing list. Yes, the patch is upstream.
>> Could you apply the patch to appropriate kernels or let me know what the next steps should be?
> 
> Hi Ronak,
> 
> there would be two options depending on urgency. If timing is less important and 
> things are applicable for upstream stable kernels as well then getting things 
> there will flow back into the Ubuntu kernels as well.
> 
> For direct submission, we need to consider it for every supported release 
> (including the upcoming one). The patch format should be that of a cherry-pick 
> -x (meaning to have a cherry picked from ...) line before the additional signed 
> off by. It would be backported from if it does not apply cleanly. Additionally 
> there should be a line
> 
> BugLink: https://bugs.launchpad.net/bugs/xxx
> 
> added (usually at the top). A patch needs to be sent only once for a set of 
> kernels it applies. IOW if it cherry picks for all only once. When the 
> format-patch is done with --cover-letter there will be a template cover email 
> generated and if that and the patch are sent together in one git send-email step 
> the patch will become a reply to the cover email. That part is because otherwise 
> cover email and patch may float independently in the email reader's view and it 
> becomes hard to link the two together.
> To help getting a list of required series, you should be able to nominate the 
> bug report for series which brings up a bullet list.

Stefan explained everything pretty nicely, so I can only add one more
thing - the process for Ubuntu is quite similar to upstream stable
process. You do it almost the same as you would send a patch to Greg KH
and other stable folks. The process differs only in:
1. Adding BugLink (which you added in the patch),
2. Preserving the cherry-pick notice mentioned by Stefan (and not adding
"commit xxx upstream" like it would be in upstream stable),
3. Adding a cover letter with explanation
(https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat)

Best regards,
Krzysztof
Krzysztof Kozlowski March 23, 2021, 1:44 p.m. UTC | #5 
On 23/03/2021 12:45, Krzysztof Kozlowski wrote:
> 
> On 23/03/2021 10:29, Stefan Bader wrote:
>> On 22.03.21 18:28, Ronak Doshi wrote:
>>>
>>> On 3/22/21, 5:38 AM, "Stefan Bader" <stefan.bader@canonical.com> wrote:
>>>
>>>> The bug asks for this to be included in all releases, Why restrict this to
>>>> Xenial and Bionic only. Also the patch is upstream
>>>>
>>>>     commit de1da8bcf40564a2adada2d5d5426e05355f66e8
>>>>     Author: Ronak Doshi <doshir@vmware.com>
>>>>     Date:   Wed Jan 27 18:08:16 2021 -0800
>>>>
>>>>          vmxnet3: Remove buf_info from device accessible structures
>>>>
>>>>     so this should be a cherry pick / backport submission. Finally the cover email
>>>>     and the patch were sent as individual emails and not as reply to the cover email
>>>>     which makes it had to keep things together.
>>>>
>>>>     -Stefan
>>>
>>> Hi Stefan,
>>>
>>> I am not sure of the process here. I usually raise a bug and the patches are ported to the
>>> kernels. This time I was asked to send the patch to this mailing list. Yes, the patch is upstream.
>>> Could you apply the patch to appropriate kernels or let me know what the next steps should be?
>>
>> Hi Ronak,
>>
>> there would be two options depending on urgency. If timing is less important and 
>> things are applicable for upstream stable kernels as well then getting things 
>> there will flow back into the Ubuntu kernels as well.
>>
>> For direct submission, we need to consider it for every supported release 
>> (including the upcoming one). The patch format should be that of a cherry-pick 
>> -x (meaning to have a cherry picked from ...) line before the additional signed 
>> off by. It would be backported from if it does not apply cleanly. Additionally 
>> there should be a line
>>
>> BugLink: https://bugs.launchpad.net/bugs/xxx


Hi Ronak,

Could you explain why is it needed on Xenial kernel (v4.4)? I understand
that the fix is important for VM guests using AMD SEV or Intel TDX. The
v4.4 Xenial kernel does not support these features (if I am not mistaken).

Best regards,
Krzysztof
diff mbox series

Patch

diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 336504b7531d..6e87f1fc4874 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -451,12 +451,8 @@  vmxnet3_tq_destroy(struct vmxnet3_tx_queue *tq,
 				  tq->comp_ring.base, tq->comp_ring.basePA);
 		tq->comp_ring.base = NULL;
 	}
-	if (tq->buf_info) {
-		dma_free_coherent(&adapter->pdev->dev,
-				  tq->tx_ring.size * sizeof(tq->buf_info[0]),
-				  tq->buf_info, tq->buf_info_pa);
-		tq->buf_info = NULL;
-	}
+	kfree(tq->buf_info);
+	tq->buf_info = NULL;
 }
 
 
@@ -505,8 +501,6 @@  static int
 vmxnet3_tq_create(struct vmxnet3_tx_queue *tq,
 		  struct vmxnet3_adapter *adapter)
 {
-	size_t sz;
-
 	BUG_ON(tq->tx_ring.base || tq->data_ring.base ||
 	       tq->comp_ring.base || tq->buf_info);
 
@@ -534,9 +528,9 @@  vmxnet3_tq_create(struct vmxnet3_tx_queue *tq,
 		goto err;
 	}
 
-	sz = tq->tx_ring.size * sizeof(tq->buf_info[0]);
-	tq->buf_info = dma_alloc_coherent(&adapter->pdev->dev, sz,
-					  &tq->buf_info_pa, GFP_KERNEL);
+	tq->buf_info = kcalloc_node(tq->tx_ring.size, sizeof(tq->buf_info[0]),
+				    GFP_KERNEL,
+				    dev_to_node(&adapter->pdev->dev));
 	if (!tq->buf_info)
 		goto err;
 
@@ -1737,13 +1731,9 @@  static void vmxnet3_rq_destroy(struct vmxnet3_rx_queue *rq,
 		rq->comp_ring.base = NULL;
 	}
 
-	if (rq->buf_info[0]) {
-		size_t sz = sizeof(struct vmxnet3_rx_buf_info) *
-			(rq->rx_ring[0].size + rq->rx_ring[1].size);
-		dma_free_coherent(&adapter->pdev->dev, sz, rq->buf_info[0],
-				  rq->buf_info_pa);
-		rq->buf_info[0] = rq->buf_info[1] = NULL;
-	}
+	kfree(rq->buf_info[0]);
+	rq->buf_info[0] = NULL;
+	rq->buf_info[1] = NULL;
 }
 
 static void
@@ -1883,10 +1873,9 @@  vmxnet3_rq_create(struct vmxnet3_rx_queue *rq, struct vmxnet3_adapter *adapter)
 		goto err;
 	}
 
-	sz = sizeof(struct vmxnet3_rx_buf_info) * (rq->rx_ring[0].size +
-						   rq->rx_ring[1].size);
-	bi = dma_alloc_coherent(&adapter->pdev->dev, sz, &rq->buf_info_pa,
-				GFP_KERNEL);
+	bi = kcalloc_node(rq->rx_ring[0].size + rq->rx_ring[1].size,
+			  sizeof(rq->buf_info[0][0]), GFP_KERNEL,
+			  dev_to_node(&adapter->pdev->dev));
 	if (!bi)
 		goto err;
 
@@ -2522,14 +2511,12 @@  vmxnet3_setup_driver_shared(struct vmxnet3_adapter *adapter)
 		tqc->txRingBasePA   = cpu_to_le64(tq->tx_ring.basePA);
 		tqc->dataRingBasePA = cpu_to_le64(tq->data_ring.basePA);
 		tqc->compRingBasePA = cpu_to_le64(tq->comp_ring.basePA);
-		tqc->ddPA           = cpu_to_le64(tq->buf_info_pa);
+		tqc->ddPA           = cpu_to_le64(~0ULL);
 		tqc->txRingSize     = cpu_to_le32(tq->tx_ring.size);
 		tqc->dataRingSize   = cpu_to_le32(tq->data_ring.size);
 		tqc->txDataRingDescSize = cpu_to_le32(tq->txdata_desc_size);
 		tqc->compRingSize   = cpu_to_le32(tq->comp_ring.size);
-		tqc->ddLen          = cpu_to_le32(
-					sizeof(struct vmxnet3_tx_buf_info) *
-					tqc->txRingSize);
+		tqc->ddLen          = cpu_to_le32(0);
 		tqc->intrIdx        = tq->comp_ring.intr_idx;
 	}
 
@@ -2541,14 +2528,11 @@  vmxnet3_setup_driver_shared(struct vmxnet3_adapter *adapter)
 		rqc->rxRingBasePA[0] = cpu_to_le64(rq->rx_ring[0].basePA);
 		rqc->rxRingBasePA[1] = cpu_to_le64(rq->rx_ring[1].basePA);
 		rqc->compRingBasePA  = cpu_to_le64(rq->comp_ring.basePA);
-		rqc->ddPA            = cpu_to_le64(rq->buf_info_pa);
+		rqc->ddPA            = cpu_to_le64(~0ULL);
 		rqc->rxRingSize[0]   = cpu_to_le32(rq->rx_ring[0].size);
 		rqc->rxRingSize[1]   = cpu_to_le32(rq->rx_ring[1].size);
 		rqc->compRingSize    = cpu_to_le32(rq->comp_ring.size);
-		rqc->ddLen           = cpu_to_le32(
-					sizeof(struct vmxnet3_rx_buf_info) *
-					(rqc->rxRingSize[0] +
-					 rqc->rxRingSize[1]));
+		rqc->ddLen           = cpu_to_le32(0);
 		rqc->intrIdx         = rq->comp_ring.intr_idx;
 		if (VMXNET3_VERSION_GE_3(adapter)) {
 			rqc->rxDataRingBasePA =
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index d958b92c9429..e910596b79cf 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -240,7 +240,6 @@  struct vmxnet3_tx_queue {
 	spinlock_t                      tx_lock;
 	struct vmxnet3_cmd_ring         tx_ring;
 	struct vmxnet3_tx_buf_info      *buf_info;
-	dma_addr_t                       buf_info_pa;
 	struct vmxnet3_tx_data_ring     data_ring;
 	struct vmxnet3_comp_ring        comp_ring;
 	struct Vmxnet3_TxQueueCtrl      *shared;
@@ -298,7 +297,6 @@  struct vmxnet3_rx_queue {
 	u32 qid2;           /* rqID in RCD for buffer from 2nd ring */
 	u32 dataRingQid;    /* rqID in RCD for buffer from data ring */
 	struct vmxnet3_rx_buf_info     *buf_info[2];
-	dma_addr_t                      buf_info_pa;
 	struct Vmxnet3_RxQueueCtrl            *shared;
 	struct vmxnet3_rq_driver_stats  stats;
 } __attribute__((__aligned__(SMP_CACHE_BYTES)));