mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-10 20:48:12 +00:00
IB/mlx4: Fix stale CM id_map entries when RTU is never received
mlx4_ib_multiplex_cm_handler() allocates an id_map_entry for CM transactions, but the entry is normally released only on DREQ or REJ flows. In the duplicate REP handling scenario, cm_dup_rep_handler() may be invoked when the remote side receives a REP for which no matching cm_id_priv exists. In such cases the CM handshake never reaches RTU, and the sender side may never receive either DREQ or REJ cleanup events. As a result, the allocated id_map_entry remains indefinitely, resulting in a stale mapping leak. Fix this by arming an RTU-abandon cleanup timeout when the id_map_entry is allocated. The timeout uses the mlx4 CM workqueue and the existing schedule_delayed() path, so later DREQ/REJ cleanup can shorten the pending timeout with mod_delayed_work(). Track whether a pending cleanup timeout is still waiting for RTU. RTU cancels only that initial timeout; if DREQ/REJ has already converted it to normal teardown cleanup, a late or duplicate RTU does not cancel the teardown timer. If the RTU timeout callback has already started, leave the entry on the timeout path and make the RTU packet lose that race. Hold id_map_lock while looking up the entry, canceling the RTU timeout, scheduling teardown cleanup, and copying the id values needed by the CM handlers. The delayed-work callback rechecks scheduled_delete under the same lock before removing and freeing the entry, avoiding use-after-free when RTU races with timeout execution. Signed-off-by: Praveen Kumar Kannoju <praveen.kannoju@oracle.com> Link: https://patch.msgid.link/20260715080738.1357072-1-praveen.kannoju@oracle.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
This commit is contained in:
parent
fbf03a0867
commit
fa09adf423
1 changed files with 87 additions and 24 deletions
Loading…
Add table
Add a link
Reference in a new issue