On 12/09/2012 17:53, Rami Rosen wrote:

 From the dump of CPU #1, it seems indeed not related at all to "modprobe -r".

Could it be that there is some IB stack sysfs write activity?
(regardless of the modprobe -r" you issued) ?  I see some candidates for it.

delete_child() is a method of the IB stack (ipoib/ipoib_main.c)

Maybe in order to help debug the problem, you might try to add in
delete_child() method, print of the name of the attribute which is being deleted?

(struct device_attribute has a a member "struct attribute attr",
which in turn has  "const char *name").

the existing dependency chain (in reverse order) is:

-> #1 (rtnl_mutex){+.+.+.}:
       [<ffffffff81072b30>] lock_acquire+0x14f/0x19b
       [<ffffffff81396a43>] mutex_lock_nested+0x64/0x2ce
       [<ffffffff812fc103>] rtnl_lock+0x12/0x14
       [<ffffffff812eecf1>] netdev_run_todo+0xa5/0x27e
       [<ffffffff812fc0dd>] rtnl_unlock+0x9/0xb
       [<ffffffffa0394889>] ipoib_vlan_delete+0x111/0x148 [ib_ipoib]
       [<ffffffffa038d29b>] delete_child+0x44/0x60 [ib_ipoib]
       [<ffffffff81247bd8>] dev_attr_store+0x1b/0x1d
       [<ffffffff8114e223>] sysfs_write_file+0x103/0x13f
       [<ffffffff810f206b>] vfs_write+0xae/0x133
       [<ffffffff810f21a9>] sys_write+0x45/0x6c
       [<ffffffff813a05e2>] system_call_fastpath+0x16/0x1b 

I've added code in ipoib_delete_child to print the caller PID and dump 
the stack,
its triggeredwhen I do "echo 0x8001 > /sys/class/net/ib0/delete_child" 
but the lockdep
warningis raised only when I actually unload the module, and no print... 
that is
ipoib_delete_child  isn't called.

Or.