<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> I don't understand the issue for now.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> Something looks wrong in the driver, and the description above.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> The adapter object seems to embed shared resources across multiple</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> eth_dev objects, is that correct?</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> If so, any function taking only a adapter pointer as input can only</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> deal with the first port related.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> This is probably the reported crash and then I would point at:</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> Fixes: 6b78a629954c ("net/cxgbe: fix queue DMA ring leaks during port close").</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> Which releases only the first port DMA resources even for another port.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> If those DMA resources are shared, the driver should not use</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> rte_eth_dma_zone_reserve() and this driver should come with its own</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> helper.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> But otherwise, if each eth_dev object has its DMA resources (which</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> seems more likely to me), then my suggestion is to pass a eth_dev</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> object to the related functions.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> And a followup cleanup would be to remove the back reference to the</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> first eth_dev in the adapter object which I find really confusing and</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> could be a source of bugs.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks for your review, I am working on the v2 based on your suggestions.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> David Marchand <david.marchand@redhat.com><br>
<b>Sent:</b> Wednesday, September 2, 2026 5:25 PM<br>
<b>To:</b> Dhanush BT. <dhanush.bt@chelsio.com><br>
<b>Cc:</b> dev@dpdk.org <dev@dpdk.org>; Potnuri Bharat Teja <bharat@chelsio.com>; stable@dpdk.org <stable@dpdk.org><br>
<b>Subject:</b> Re: [PATCH] net/cxgbe: fix use-after-free in control queue teardown</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Wed, 2 Sept 2026 at 11:47, B T Dhanush <dhanush.bt@chelsio.com> wrote:<br>
><br>
> t4_free_sge_resources() frees ctrl Tx queue and firmware event queue<br>
> DMA memzones using adapter->eth_dev, read at teardown time. This<br>
> runs only once, when the last port on the adapter closes.<br>
><br>
> rte_eth_dev_close() frees a port's eth_dev->data right after that<br>
> port's own dev_close() returns, regardless of other ports' state. If<br>
> port 0 is not the last port closed, adapter->eth_dev->data is already<br>
> freed by the time t4_free_sge_resources() runs, causing a NULL<br>
> pointer dereference in rte_eth_dma_zone_free() and a crash on exit.<br>
><br>
> Fix by not dereferencing eth_dev at teardown. Store the port_id used<br>
> for each queue's memzone name at allocation time instead, and free<br>
> each memzone directly via rte_memzone_lookup()/rte_memzone_free().<br>
><br>
> Fixes: 36c46e738120 ("ethdev: cleanup shared data with the last port")<br>
<br>
This commit may have made the bug more visible but I doubt this is the<br>
reason for the reported issue.<br>
<br>
> Cc: stable@dpdk.org<br>
><br>
> Signed-off-by: B T Dhanush <dhanush.bt@chelsio.com><br>
> Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com><br>
<br>
I don't understand the issue for now.<br>
Something looks wrong in the driver, and the description above.<br>
<br>
The adapter object seems to embed shared resources across multiple<br>
eth_dev objects, is that correct?<br>
If so, any function taking only a adapter pointer as input can only<br>
deal with the first port related.<br>
<br>
This is probably the reported crash and then I would point at:<br>
Fixes: 6b78a629954c ("net/cxgbe: fix queue DMA ring leaks during port close").<br>
Which releases only the first port DMA resources even for another port.<br>
<br>
If those DMA resources are shared, the driver should not use<br>
rte_eth_dma_zone_reserve() and this driver should come with its own<br>
helper.<br>
<br>
But otherwise, if each eth_dev object has its DMA resources (which<br>
seems more likely to me), then my suggestion is to pass a eth_dev<br>
object to the related functions.<br>
And a followup cleanup would be to remove the back reference to the<br>
first eth_dev in the adapter object which I find really confusing and<br>
could be a source of bugs.<br>
<br>
<br>
-- <br>
David Marchand<br>
<br>
</div>
</span></font></div>
</body>
</html>