Linux kernel (drivers/infiniband/core): A peer that drives enough connection churn across a node's IB port pushes the

Impact

A peer that drives enough connection churn across a node's IB port pushes the MAD agent timeout handler into per-request lock thrashing, parking a CPU in the ib_mad workqueue for tens of seconds. Reported as a hard soft-lockup on production RDMA nodes, this is a whole-node stall that every tenant sharing the box feels, not a single-process hang.

Who can reach it

Reachable from the fabric with no authentication: MAD traffic and rdma_cm connection setup between peer nodes is what generates the timed-out work requests. A tenant container holding /dev/infiniband/rdma_cm or uverbs can generate the same connection churn locally. No special device state needed beyond a live IB/RoCE port with the ib_cm/rdma_cm path in use.

What to do

No fixed version is recorded in this entry; boot a stable kernel that carries the ib_mad timeout batching fix (commits 713adaf0ecfc / 7022a517bf1c). There is no meaningful interim control other than limiting who can open RDMA connections to the node's ports (fabric ACLs, partition keys) and dropping /dev/infiniband from tenants that do not need it.

References