On Tue, Aug 04, 2015 at 06:26:58AM -0700, Tadeusz Struk wrote: > > 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 :) What if someone calls adf_remove? For a software implementation you can prevent the algorithm from going away by holding module reference counts. But a device can always be removed and you're not going to stop that no matter how many reference counts you hold :) Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
