I work on implementation of driver for Linuc CryptoApi. Encryption/decryption will be performed in hardware and I want to use asynchronous operation of CryptoApi, which perfectly suitable for this purpose. Main purpose of driver is using with ipsec.

Citation from documentation:

Asynchronous operation is provided by the kernel crypto API which implies that the invocation of a cipher operation will complete almost instantly. That invocation triggers the cipher operation but it does not signal its completion. Before invoking a cipher operation, the caller must provide a callback function the kernel crypto API can invoke to signal the completion of the cipher operation. Furthermore, the caller must ensure it can handle such asynchronous events by applying appropriate locking around its data. The kernel crypto API does not perform any special serialization operation to protect the caller’s data integrity.

Common mechanism of work: driver get query for processing data, make child process which will communicate with hardware, then driver(not child process) return special code("in progress") to caller. Caller now can create one else query or do another useful work. When data processing complete child process call callback function, which registered by caller, and die.

But caller of the driver can be killed, for example, before data will be handled by hardware. If caller process not exist anymore in system, execution callback function can corrupt system. Besides that, before execution of callback function child process get encrypted/decrypted data from hardware and write it to some buffer, which was provided by caller. And this is one more scenario of system corruption. If caller not exist anymore driver should not use buffer.

How did kernel developers planned me to resolve this issue? What mechanism of synchronization between my driver and customer application should I use?

And I want to go back to upper citation: Furthermore, the caller must ensure it can handle such asynchronous events by applying appropriate locking around its data. The kernel crypto API does not perform any special serialization operation to protect the caller’s data integrity.

I don't know, but it can concern to issue I research. In that case it's not problem of my driver to control data integrity. Then maybe it's a problem of ipsec level? For example, xfrm subsystem?

Any comments or ideas, please?

And I create appropriate topic at stackoverflow, maybe it will be helpfull too.