When the device is removed all allocated resources should be freed.
In uhdlc_memclean the netdev transmit queue was already stopped. But at
this point we may have pending skb in the transmit queue which must be
freed. Therefore iterate over the tx_skbuff pointers and free all
pending skb. The issue was discovered by sashiko.
https://sashiko.dev/#/patchset/20260429114208.941011-1-holger.brunck%40hitachienergy.com
Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
Signed-off-by: Holger Brunck <redacted>
---
v2: - use dev_kfree_skb instead of kfree
- improve commit message
- add missing paramter in for statement
v1: https://lore.kernel.org/linuxppc-dev/20260504161145.2217950-1-holger.brunck@hitachienergy.com/
drivers/net/wan/fsl_ucc_hdlc.c | 7 +++++++
1 file changed, 7 insertions(+)
From: Jakub Kicinski <kuba@kernel.org> Date: 2026-05-06 23:16:34
On Wed, 6 May 2026 13:15:29 +0200 Holger Brunck wrote:
When the device is removed all allocated resources should be freed.
In uhdlc_memclean the netdev transmit queue was already stopped. But at
this point we may have pending skb in the transmit queue which must be
freed. Therefore iterate over the tx_skbuff pointers and free all
pending skb. The issue was discovered by sashiko.
And you tested this how?
Given the questionable v1 I'm highly hesitant to accept patches
from you if you can't test them.
On Wed, 6 May 2026 13:15:29 +0200 Holger Brunck wrote:
quoted
When the device is removed all allocated resources should be freed.
In uhdlc_memclean the netdev transmit queue was already stopped. But
at this point we may have pending skb in the transmit queue which must
be freed. Therefore iterate over the tx_skbuff pointers and free all
pending skb. The issue was discovered by sashiko.
And you tested this how?
Given the questionable v1 I'm highly hesitant to accept patches from you if you
can't test them.
I tested the patch on a ls1043a board running HDLC in busmode on kernel 6.12
I was able to queue some packets in the TX part simply in removing the TX clock
for my setup. When I then shutdown the interface and remove the module I can
see that thel sk_buff pointers stored in the priv->tx_skbuff array, are not freed
without the patch in question.
I am currently not able to run my setup on latest master, but the changes in the
driver compared to master are minimal.
Best regards
Holger
From: Jakub Kicinski <kuba@kernel.org> Date: 2026-05-07 15:35:15
On Thu, 7 May 2026 15:07:35 +0000 Holger Brunck wrote:
quoted
On Wed, 6 May 2026 13:15:29 +0200 Holger Brunck wrote:
quoted
When the device is removed all allocated resources should be freed.
In uhdlc_memclean the netdev transmit queue was already stopped. But
at this point we may have pending skb in the transmit queue which must
be freed. Therefore iterate over the tx_skbuff pointers and free all
pending skb. The issue was discovered by sashiko.
And you tested this how?
Given the questionable v1 I'm highly hesitant to accept patches from you if you
can't test them.
I tested the patch on a ls1043a board running HDLC in busmode on kernel 6.12
Please add this to the commit message, as previously requested.