New: ib_srp module removal triggers circular locking complaint

http://bugzilla.kernel.org/show_bug.cgi?id=15095

Summary: ib_srp module removal triggers circular locking
complaint
Product: Drivers
Version: 2.5
Kernel Version: 2.6.33-rc3 (infiniband.git tree, for-next branch, last
commit dates from Thu Jan 14 12:23:37 2010 -0800)
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Infiniband/RDMA
AssignedTo: drivers_infiniband-rdma-ztI5WcYan/[email protected]
ReportedBy: [email protected]
Regression: No

Created an attachment (id=24662)
--> (http://bugzilla.kernel.org/attachment.cgi?id=24662)
Kernel log

Removing the ib_srp kernel module often (but not always) triggers a kernel complaint about a possible circular locking dependency.

That complaint is triggered by the following script:

#!/bin/sh
while [ -e /sys/module/ib_srp ]
do
rmmod ib_srp || sleep 1
done
modprobe ib_srp "${1:-srp_sg_tablesize=128}"
ibsrpdm -c -d /dev/infiniband/umad0 \
| while read target_info
do

    echo "${target_info}"
    echo "${target_info}" > /sys/class/infiniband_srp/srp-mlx4_0-1/add_target

done

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Looks like a sysfs problem or maybe a SCSI - sysfs interaction that doesn't have much to do with ib_srp in particular. The two locks involved, namely s_active and attribute_container_mutex, are completely outside of ib_srp and are taken out of its control.

This is probably triggering now because of the new commit 846f9974 ("sysfs: Add lockdep annotations for the sysfs active reference") that is tracking s_active nesting now.

- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html