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>
Subject: Re: Memory leak in ieee80211_rx_napi()
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless <linux-wireless@vger.kernel.org>,
        Pkshih <pkshih@realtek.com>
References: <ad9bee4f-ef24-1fe0-5e63-e2e840ac0449@lwfinger.net>
 <82a7c6c9bcbe923906276e8aa26a9a783598a0d7.camel@sipsolutions.net>
From:   Larry Finger <Larry.Finger@lwfinger.net>
Message-ID: <32687519-1c0e-1e6c-dbc3-1e9fd027fc8a@lwfinger.net>
Date:   Sun, 11 Apr 2021 14:17:39 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <82a7c6c9bcbe923906276e8aa26a9a783598a0d7.camel@sipsolutions.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 4/9/21 2:31 PM, Johannes Berg wrote:
> Hi Larry,
> 
>> What setting or lack of, would cause ieee80211_rx_napi() to leak the skb that it
>> is given? The documentation states that once this call is made, mac80211 owns
>> this buffer. Does this mean that it will also be freed?
> 
> Eventually, yes. But it might go onto a NAPI GRO list, etc. Perhaps it
> might even look like it's leaked if it's on such a list if you didn't
> implement NAPI properly as polling, but just call ieee80211_rx_napi()
> with a non-NULL napi struct pointer.

Hi Johannes,

There were two bugs in rtw88. The first, suggested by PK, was that the sequence 
between start/stop of NAPI and the enable/disable of interrupts were reversed. 
The second bug was in NAPI polling as you suggested. The poll routine was 
calling napi_schedule() rather than napi_reschedule().

With these two changes, my RTL8822CE handled 12 hours of flood ping with my 
router without leaking a single buffer.

Thanks for your help,

Larry