From: Michael Pfeifroth <micpf@westermo.com>
To: Baochen Qiang <baochen.qiang@oss.qualcomm.com>,
Jeff Johnson <jjohnson@kernel.org>
Cc: Kalle Valo <kvalo@kernel.org>,
ath11k@lists.infradead.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] wifi: ath11k: release peer accounting on peer delete timeout
Date: Thu, 24 Sep 2026 11:13:57 +0200 [thread overview]
Message-ID: <arTp1bbipr6FceMH@mpf-ESPRIMO-P9012> (raw)
In-Reply-To: <9d8307ee-e9bd-4538-92f8-b33410caecae@oss.qualcomm.com>
On 9/24/2026 9:29 AM, Baochen Qiang wrote:
>> On such a timeout __ath11k_peer_delete() returns early without removing
>> the local peer object, and ath11k_peer_delete() consequently skips the
>> ar->num_peers-- decrement (it only runs on the success path). The normal
>> free happens asynchronously in ath11k_peer_unmap_event(), which never
> Hmm, I don't think so. host waits for peer unmap event in ath11k_wait_for_peer_deleted(),
> before waiting for peer delete response. Since there is no "failed wait for peer deleted"
> log, unmap event is good and ath11k_peer_unmap_event() runs.
You are right, thanks. The unmap event is received, so the peer is
already removed from ab->peers and freed; what actually leaks is only the
ar->num_peers counter, because __ath11k_peer_delete() returns -ETIMEDOUT
from the *second* wait (the delete-response completion) and
ath11k_peer_delete() therefore skips the num_peers-- decrement.
So the essential fix is to return success on the timeout path. The
list_del()/kfree() is only a safety net for the other timeout case, where
ath11k_wait_for_peer_deleted() itself times out and no unmap event ever
removed the peer; that is why it is guarded by "if (peer)". I have
reworded the commit message and the code comment accordingly in v2.
>> runs when the delete response is lost or misrouted (e.g. because the
> what does 'misrouted' mean?
Poor wording on my side, dropped in v2. What I meant is the case you
describe below: the delete-response event is dropped in
ath11k_peer_delete_resp_event() because ath11k_mac_get_ar_by_vdev_id()
cannot resolve the vdev id (the "invalid vdev id in peer delete resp ev"
warning), so complete(&ar->peer_delete_done) is never called and the
wait times out even though firmware did delete the peer.
>> The problem was reproduced deterministically with a fault-injection
> curious what the patch does? does it modify ath11k codebase?
Yes, it is an out-of-tree debug-only patch (not part of this submission).
It adds a few module parameters to ath11k: one forces the next N
ath11k_wait_for_peer_delete_done() calls to return -ETIMEDOUT, and one
caps max_num_peers so the ceiling is hit after only a few deletes. With
the counter leak in place the AP stops accepting new stations after
max_num_peers forced timeouts; with this fix it keeps accepting them.
I have addressed the comment style (/* on its own first line) in v2 as
well. v2 follows shortly.
Thanks,
Michael
next prev parent reply other threads:[~2026-09-24 9:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 12:25 Michael Pfeifroth
2026-09-24 7:29 ` Baochen Qiang
2026-09-24 9:13 ` Michael Pfeifroth [this message]
2026-09-24 9:14 ` [PATCH v2] " Michael Pfeifroth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=arTp1bbipr6FceMH@mpf-ESPRIMO-P9012 \
--to=micpf@westermo.com \
--cc=ath11k@lists.infradead.org \
--cc=baochen.qiang@oss.qualcomm.com \
--cc=jjohnson@kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®