I wrote: > But the interaction with userspace processes opening /dev/fwX while the > respective node is being shut down gave me headaches. I am still not > entirely sure if I got it right in the patch update, i.e. if it is free > from deadlocks. fw_device_shutdown() and fw_device_op_open() can be > entered at the same time. Would device_unregister() have to acquire a > driver core lock which open() already took? If yes, device_unregister() > would be blocked on this lock while fw_device_op_open() is blocked on > idr_rwsem. > > So why did I move device_unregister() into the idr_rwsem protected > section in the first place? That's because I wanted to guarantee that > fw_device_op_open() wouldn't look up a fw_device which is just in the > process of being unregistered. But maybe we don't even need this guarantee.
Did some further thinking: Yes, I have to guarantee that the pointer which the lookup in the idr tree returned is valid. But I don't have to shove device_unregister() into the idr_rwsem locked section. Instead, I can (and actually should) increment the device's refcount when I stick the device pointer into the idr tree. (And of course I decrease the refcount again when I remove the pointer from the idr tree.) Will probably post another update tomorrow. -- Stefan Richter -=====-==--- ---= ===-= http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
