[PATCH] wifi: ath11k: release peer accounting on peer delete timeout

[Michael Pfeifroth <micpf@westermo.com>]

On some deployments access points intermittently stop accepting new
station associations after several hours of uptime with frequent
roaming/reconnects. The kernel logs

  ath11k_pci ....: failed to create peer due to insufficient peer entry resource in firmware

and hostapd reports "Could not add STA to kernel driver". A "wifi
down/up" (radio restart) on the affected radio restores service.

Despite the message text, this is not a firmware peer-table exhaustion.
The message is emitted by the driver-side gate in ath11k_peer_create():

	if (ar->num_peers > (ar->max_num_peers - 1))

i.e. the driver's own ar->num_peers accounting has leaked and reached
the ceiling. It is always preceded by a peer-delete that timed out:

  ath11k_pci ....: invalid vdev id in peer delete resp ev 1
  ath11k_pci ....: Timeout in receiving peer delete response
  ath11k_pci ....: failed to delete peer vdev_id .. addr .. ret -110

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
runs when the delete response is lost or misrouted (e.g. because the
vdev is already gone by the time the response is processed, hence the
"invalid vdev id in peer delete resp ev" warning). Each timed-out delete
therefore leaks one ar->num_peers slot until max_num_peers is reached
and all further ath11k_peer_create() calls fail.

Free the local peer on the timeout path and return success so that
ath11k_peer_delete() releases the num_peers slot. The peer has already
been removed from the rhash earlier in __ath11k_peer_delete(), so only
the list removal and free remain, mirroring ath11k_peer_unmap_event().
A late unmap event will then simply fail to find the peer id and log a
harmless warning instead of touching freed memory.

The problem was reproduced deterministically with a fault-injection
patch that forces the peer-delete wait to time out: after max_num_peers
such deletes the AP permanently rejects new stations, and with this
change it keeps accepting them.

Fixes: 690ace20ff79 ("ath11k: peer delete synchronization with firmware")
Cc: stable@vger.kernel.org
Signed-off-by: Michael Pfeifroth <micpf@westermo.com>
---
 drivers/net/wireless/ath/ath11k/peer.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/peer.c b/drivers/net/wireless/ath/ath11k/peer.c
index b30a906..ed2d7d8 100644
--- a/drivers/net/wireless/ath/ath11k/peer.c
+++ b/drivers/net/wireless/ath/ath11k/peer.c
@@ -341,8 +341,20 @@ static int __ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, const u8 *addr)
 	}
 
 	ret = ath11k_wait_for_peer_delete_done(ar, vdev_id, addr);
-	if (ret)
-		return ret;
+	if (ret) {
+		/* The firmware delete confirmation was lost; free the local
+		 * peer here (already removed from the rhash above) so that
+		 * ath11k_peer_delete() releases the ar->num_peers slot instead
+		 * of leaking it.
+		 */
+		spin_lock_bh(&ab->base_lock);
+		peer = ath11k_peer_find(ab, vdev_id, addr);
+		if (peer) {
+			list_del(&peer->list);
+			kfree(peer);
+		}
+		spin_unlock_bh(&ab->base_lock);
+	}
 
 	return 0;
 }
-- 
2.34.1