IB/mlx4: Avoid requeueing executing CM timeout work

id->scheduled_delete is set by schedule_delayed() itself.  It is used
in two cases after the RTU timeout support was added:

* A new id_map_entry is created, and a 60-second RTU timeout is
  scheduled.
* DREQ or REJ is received for an existing entry, and the normal
  30-second teardown timeout is scheduled or adjusted.

The following race is possible when the RTU timeout expires while a
DREQ or REJ is handled:

 CPU 0: timeout work                         CPU 1: DREQ/REJ handler
 --------------------                        -----------------------
 RTU timer expires
 timeout callback starts
 waits for id_map_lock                       takes id_map_lock

                                             calls schedule_delayed()
                                             calls mod_delayed_work()

                                             drops id_map_lock

 takes id_map_lock
 removes mapping
 frees id_map_entry

                                             requeued timeout runs
                                             accesses freed id_map_entry

mod_delayed_work() may requeue the work after the timeout callback has
started.  The original timeout callback then frees the id_map_entry,
leaving the requeued work with a dangling delayed_work pointer.

When a timeout is already scheduled, first cancel its pending work.  A
successful cancellation means the callback has not started and the
timeout can safely be scheduled again.  If cancellation fails, the
callback is executing and will free the entry after id_map_lock is
released; do not requeue it.

cancel_delayed_work() is deliberately used instead of
cancel_delayed_work_sync(), because the timeout callback may be waiting
for id_map_lock, which is held by the caller.

Fixes: fa09adf4231f ("IB/mlx4: Fix stale CM id_map entries when RTU is never received")
Signed-off-by: Praveen Kumar Kannoju <praveen.kannoju@oracle.com>
Link: https://patch.msgid.link/20261014121344.100048-1-praveen.kannoju@oracle.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>

0 files changed, 0 insertions, 0 deletions