Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: Larry Finger <larry.finger@gmail.com>
From:   Larry Finger <Larry.Finger@lwfinger.net>
Subject: Memory leak in rtw88-pci
To:     linux-wireless <linux-wireless@vger.kernel.org>
Message-ID: <83a9aeff-ce2c-3442-90fa-7e190acf3dfe@lwfinger.net>
Date:   Fri, 26 Mar 2021 11:30:44 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

Kmemleak shows the following leaks:

unreferenced object 0xffff888114146a00 (size 512):
   comm "softirq", pid 0, jiffies 4294910753 (age 28.196s)
   hex dump (first 32 bytes):
     08 42 00 00 01 00 5e 00 08 42 00 00 01 00 5e 00  .B....^..B....^.
     00 fb 84 1b 5e f7 6b 02 00 e0 01 00 5e 00 00 fb  ....^.k.....^...
   backtrace:
     [<0000000068bda00b>] kmalloc_reserve+0x2d/0x70
     [<000000006234ee4e>] __alloc_skb+0x8c/0x250
     [<00000000fd066823>] __netdev_alloc_skb+0x3f/0x150
     [<000000002b8b6774>] rtw_pci_rx_napi.constprop.0+0x1c7/0x310 [rtw88_pci]
     [<0000000071d79fc5>] rtw_pci_napi_poll+0x47/0xf0 [rtw88_pci]
     [<000000005b3960c0>] __napi_poll+0x2a/0x160
     [<00000000f87d43ad>] net_rx_action+0x234/0x280
     [<0000000065ab9dcb>] __do_softirq+0xbf/0x285
     [<000000002a7f930b>] do_softirq+0x61/0x80
     [<0000000020308f21>] __local_bh_enable_ip+0x4b/0x50
     [<00000000c4d6ca98>] rtw_pci_interrupt_threadfn+0xb2/0x1f0 [rtw88_pci]
     [<0000000045d500ae>] irq_thread_fn+0x20/0x60
     [<00000000d00af633>] irq_thread+0xa0/0x150
     [<000000007c7898b7>] kthread+0x134/0x150
     [<0000000083df94f0>] ret_from_fork+0x22/0x30

That address in rtw_pci_rx_napi points to the dev_alloc_skb() call in the 
following snippit:

                 /* allocate a new skb for this frame,
                  * discard the frame if none available
                  */
                 new_len = pkt_stat.pkt_len + pkt_offset;
=====>          new = dev_alloc_skb(new_len);
                 if (WARN_ONCE(!new, "rx routine starvation\n"))
                         goto next_rp;

                 /* put the DMA data including rx_desc from phy to new skb */
                 skb_put_data(new, skb->data, new_len);

                 if (pkt_stat.is_c2h) {
                         rtw_fw_c2h_cmd_rx_irqsafe(rtwdev, pkt_offset, new);
                 } else {
                         /* remove rx_desc */
                         skb_pull(new, pkt_offset);

                         rtw_rx_stats(rtwdev, pkt_stat.vif, new);
                         memcpy(new->cb, &rx_status, sizeof(rx_status));
                         ieee80211_rx_napi(rtwdev->hw, NULL, new, napi);
                         rx_done++;
                 }

Clearly, the allocated skb is never freed. These allocated blocks do not 
disappear when the driver is unloaded, thus these reports are not false 
positives, but are real memory leaks.

I followed the code in rtw_fw_c2h_cmd_rx_irqsafe() and determined that it is 
freeing the skb, thus the problem is in the branch that calls 
ieee80211_rx_napi(); however, as far as I can tell, this code matches other drivers.

Larry