On 08/04/2015 02:59 AM, Herbert Xu wrote: > Good catch. However it's not as simple as that. We have a bigger > problem here. > > For software implementations it's really easy because we use the > module reference count to prevent unregisters from happening while > there are tfms using it. > > However for hardware devices this breaks down because you can remove > the device at any time. So we'll have to come up with a way of > handling this without causing live tfms to explode. > > FWIW the current qat code (and possibly other drivers) is buggy > because if you call unregister while there are still tfms using > it, it will BUG in the unregister call. The way we handle it in qat is as follows - when tfm allocates a crypto "instance" on a qat dev it then calls qat_crypto_put_instance(), which calls also adf_dev_put() on the appropriate qat device. This then calls module_put() on accel_dev->owner. This way, when any tfm is allocated on a device the attempts to rmmod or ioctl shutdown returns -EBUSY. See adf_ctl_is_device_in_use() One can only successfully shut down a device or rmmod qat_dh895 when all tfms are freed. The only possibility when we may try to restart a device when tfms are allocated is when we handle HW uncorrectable errors, which in theory should never happen :) -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
