From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kalle Valo Date: Tue, 14 May 2013 07:29:38 +0300 Subject: [ath9k-devel] [PATCH] ath10k: serialize CE completions properly In-Reply-To: <1368189803-14177-1-git-send-email-michal.kazior@tieto.com> (Michal Kazior's message of "Fri, 10 May 2013 14:43:23 +0200") References: <1368007238-27296-1-git-send-email-michal.kazior@tieto.com> <1368189803-14177-1-git-send-email-michal.kazior@tieto.com> Message-ID: <87a9nytc99.fsf@kamboji.qca.qualcomm.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org Michal Kazior writes: > This fixes memory leak when doing heavy TX. > > ath10k_pci_check_process_ce() was checking > `compl_processing` and would call > ath10k_pci_process_ce() if its false. The > ath10k_pci_process_ce() would then set it to true > if there's at least one completion. The lock > protecting the variable is not held between > checking and setting the variable, meaning it is a > possible race condition. > > If we then assume ath10k_pci_process_ce() is > called simultaneusly from different contexts we > have a race. And apparently this was possible: > > ath10k_pci_check_process_ce() was called from > ath10k_ce_per_engine_service(). This in turn could > be called either from multiple tasklets (MSI-X) or > a tasklet (MSI, Legacy INTR) or > ath10k_htc_send_complete_check(). > > The race itself would cause corruption of > htt.refcount (ath10k_skb_cb) and we'd leak > multiple skbuffs per tx. > > Signed-off-by: Michal Kazior Thanks, applied. -- Kalle Valo