![]() Holding agent->lock across cancel_delayed_work() (which does del_timer_sync()) in ib_cancel_rmpp_recvs() leads to lockdep reports of possible lock-timer deadlocks if a consumer ever does something that connects agent->lock to a lock taken in IRQ context (cf http://marc.info/?l=linux-rdma&m=125243699026045). Fix this by changing the list items to a new state "CANCELING" while holding the lock, and then canceling the delayed work without holding the lock. If the delayed work runs after the lock is dropped, it will see the state is CANCELING and return immediately, so the list will stay stable while we traverse it with the lock not held. Reviewed-by: Sean Hefty <sean.hefty@intel.com> Signed-off-by: Roland Dreier <rolandd@cisco.com> |
||
---|---|---|
.. | ||
addr.c | ||
agent.c | ||
agent.h | ||
cache.c | ||
cm.c | ||
cm_msgs.h | ||
cma.c | ||
core_priv.h | ||
device.c | ||
fmr_pool.c | ||
iwcm.c | ||
iwcm.h | ||
mad.c | ||
mad_priv.h | ||
mad_rmpp.c | ||
mad_rmpp.h | ||
Makefile | ||
multicast.c | ||
packer.c | ||
sa.h | ||
sa_query.c | ||
smi.c | ||
smi.h | ||
sysfs.c | ||
ucm.c | ||
ucma.c | ||
ud_header.c | ||
umem.c | ||
user_mad.c | ||
uverbs.h | ||
uverbs_cmd.c | ||
uverbs_main.c | ||
uverbs_marshall.c | ||
verbs.c |