Hi,
i tested the EDIMAX EW-7612 on Raspberry Pi 3B+ with Linux 5.4-rc5
(multi_v7_defconfig + rtlwifi + kmemleak) and noticed a single memory
leak during probe:
unreferenced object 0xec13ee40 (size 176):
comm "kworker/u8:1", pid 36, jiffies 4294939321 (age 5580.790s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<fc1bbb3e>] __netdev_alloc_skb+0x9c/0x164
[<863dfa6e>] rtl92c_set_fw_rsvdpagepkt+0x254/0x340 [rtl8192c_common]
[<9572be0d>] rtl92cu_set_hw_reg+0xf48/0xfa4 [rtl8192cu]
[<116df4d8>] rtl_op_bss_info_changed+0x234/0x96c [rtlwifi]
[<8933575f>] ieee80211_bss_info_change_notify+0xb8/0x264 [mac80211]
[<d4061e86>] ieee80211_assoc_success+0x934/0x1798 [mac80211]
[<e55adb56>] ieee80211_rx_mgmt_assoc_resp+0x174/0x314 [mac80211]
[<5974629e>] ieee80211_sta_rx_queued_mgmt+0x3f4/0x7f0 [mac80211]
[<d91091c6>] ieee80211_iface_work+0x208/0x318 [mac80211]
[<ac5fcae4>] process_one_work+0x22c/0x564
[<f5e6d3b6>] worker_thread+0x44/0x5d8
[<82c7b073>] kthread+0x150/0x154
[<b43e1b7d>] ret_from_fork+0x14/0x2c
[<794dff30>] 0x0
It looks like the allocated skd is never freed.
Would be nice to get this fixed.
Regards
Stefan
> -----Original Message-----
> From: Stefan Wahren [mailto:[email protected]]
> Sent: Thursday, October 31, 2019 9:57 PM
> To: Pkshih; Larry Finger
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]
> Subject: rtlwifi: Memory leak in rtl92c_set_fw_rsvdpagepkt()
>
> Hi,
>
> i tested the EDIMAX EW-7612 on Raspberry Pi 3B+ with Linux 5.4-rc5
> (multi_v7_defconfig + rtlwifi + kmemleak) and noticed a single memory
> leak during probe:
>
> unreferenced object 0xec13ee40 (size 176):
> comm "kworker/u8:1", pid 36, jiffies 4294939321 (age 5580.790s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<fc1bbb3e>] __netdev_alloc_skb+0x9c/0x164
> [<863dfa6e>] rtl92c_set_fw_rsvdpagepkt+0x254/0x340 [rtl8192c_common]
> [<9572be0d>] rtl92cu_set_hw_reg+0xf48/0xfa4 [rtl8192cu]
> [<116df4d8>] rtl_op_bss_info_changed+0x234/0x96c [rtlwifi]
> [<8933575f>] ieee80211_bss_info_change_notify+0xb8/0x264 [mac80211]
> [<d4061e86>] ieee80211_assoc_success+0x934/0x1798 [mac80211]
> [<e55adb56>] ieee80211_rx_mgmt_assoc_resp+0x174/0x314 [mac80211]
> [<5974629e>] ieee80211_sta_rx_queued_mgmt+0x3f4/0x7f0 [mac80211]
> [<d91091c6>] ieee80211_iface_work+0x208/0x318 [mac80211]
> [<ac5fcae4>] process_one_work+0x22c/0x564
> [<f5e6d3b6>] worker_thread+0x44/0x5d8
> [<82c7b073>] kthread+0x150/0x154
> [<b43e1b7d>] ret_from_fork+0x14/0x2c
> [<794dff30>] 0x0
>
> It looks like the allocated skd is never freed.
>
> Would be nice to get this fixed.
>
Hi,
This is due to 8192cu doesn't implement usb_cmd_send_packet(). Could you help
following patch?
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
index 56cc3bc30860..f070f25bb735 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
@@ -1540,6 +1540,8 @@ static bool usb_cmd_send_packet(struct ieee80211_hw *hw, struct sk_buff *skb)
* This is maybe necessary:
* rtlpriv->cfg->ops->fill_tx_cmddesc(hw, buffer, 1, 1, skb);
*/
+ dev_kfree_skb(skb);
+
return true;
}
This patch just frees the skb to resolve memleak problem. Since 8192cu doesn't
turn on fwctrl_lps that needs to download command packet to firmware, apply
this patch isn't worse than before.
---
PK
Am 01.11.19 um 02:18 schrieb Pkshih:
>
>> -----Original Message-----
>> From: Stefan Wahren [mailto:[email protected]]
>> Sent: Thursday, October 31, 2019 9:57 PM
>> To: Pkshih; Larry Finger
>> Cc: [email protected]; [email protected]; [email protected];
>> [email protected]
>> Subject: rtlwifi: Memory leak in rtl92c_set_fw_rsvdpagepkt()
>>
>> Hi,
>>
>> i tested the EDIMAX EW-7612 on Raspberry Pi 3B+ with Linux 5.4-rc5
>> (multi_v7_defconfig + rtlwifi + kmemleak) and noticed a single memory
>> leak during probe:
>>
>> unreferenced object 0xec13ee40 (size 176):
>> comm "kworker/u8:1", pid 36, jiffies 4294939321 (age 5580.790s)
>> hex dump (first 32 bytes):
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<fc1bbb3e>] __netdev_alloc_skb+0x9c/0x164
>> [<863dfa6e>] rtl92c_set_fw_rsvdpagepkt+0x254/0x340 [rtl8192c_common]
>> [<9572be0d>] rtl92cu_set_hw_reg+0xf48/0xfa4 [rtl8192cu]
>> [<116df4d8>] rtl_op_bss_info_changed+0x234/0x96c [rtlwifi]
>> [<8933575f>] ieee80211_bss_info_change_notify+0xb8/0x264 [mac80211]
>> [<d4061e86>] ieee80211_assoc_success+0x934/0x1798 [mac80211]
>> [<e55adb56>] ieee80211_rx_mgmt_assoc_resp+0x174/0x314 [mac80211]
>> [<5974629e>] ieee80211_sta_rx_queued_mgmt+0x3f4/0x7f0 [mac80211]
>> [<d91091c6>] ieee80211_iface_work+0x208/0x318 [mac80211]
>> [<ac5fcae4>] process_one_work+0x22c/0x564
>> [<f5e6d3b6>] worker_thread+0x44/0x5d8
>> [<82c7b073>] kthread+0x150/0x154
>> [<b43e1b7d>] ret_from_fork+0x14/0x2c
>> [<794dff30>] 0x0
>>
>> It looks like the allocated skd is never freed.
>>
>> Would be nice to get this fixed.
>>
> Hi,
>
> This is due to 8192cu doesn't implement usb_cmd_send_packet(). Could you help
> following patch?
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
> index 56cc3bc30860..f070f25bb735 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
> @@ -1540,6 +1540,8 @@ static bool usb_cmd_send_packet(struct ieee80211_hw *hw, struct sk_buff *skb)
> * This is maybe necessary:
> * rtlpriv->cfg->ops->fill_tx_cmddesc(hw, buffer, 1, 1, skb);
> */
> + dev_kfree_skb(skb);
> +
> return true;
> }
>
> This patch just frees the skb to resolve memleak problem. Since 8192cu doesn't
> turn on fwctrl_lps that needs to download command packet to firmware, apply
> this patch isn't worse than before.
Yes, the patch fixes the memleak.
Thanks
Stefan
>
> ---
> PK
>