On 7/6/2023 12:58 AM, Herbert Xu wrote: > On Wed, Jul 05, 2023 at 09:57:54PM +0100, Giovanni Cabiddu wrote: >> >> Then we are then back to square one. We need to check how many entries >> are present in the scatterlists encrypted by crypt_journal() before >> adjusting the meaning of !CRYPTO_ALG_ALLOCATES_MEMORY. > > Indeed. I missed the fact that it was preallocating memory with > GFP_KERNEL. > > So perhaps the answer is to adjust our API to allow the drivers to > pre-allocate memory. I'll look into this. > Reviving this thread, trying to reach a conclusion. Herbert, do you have any suggestion on how to move forward? Is preallocating memory at crypto request allocation time worth pursuing? This would indeed require updating the crypto API, to allow users to provide, optionally, hints to the drivers / crypto framework wrt. memory needed (e.g. S/G sizes): *_request_alloc(tfm, gfp, prealloc_hint); Taking dm-integrity as an example, quoting Mikulas "dm-integrity allocates arbitrarily large sg-lists when encrypting the journal" so it's unpractical for drivers to use tfm->reqsize for memory preallocation. OTOH, the sizes of S/Gs are known at crypto request allocation time: create_journal -> dm_integrity_alloc_journal_scatterlist -> skcipher_request_alloc For dm-crypt, we can't use the same logic, since crypto requests are allocated from a mempool and *_request_alloc API is not used. Fortunately, the S/G sizes are bounded and fairly small, thus drivers could use tfm->reqsize to cover this case. If the user / application logic expects no memory allocation at "runtime", then it follows it has some information wrt. resources to be used and either allocates crypto requests early on (dm-integrity) or prepares a mempool (dm-crypt). This information should be propagated to the drivers / crypto framework. It's unreasonable to expect HW-backed implementations to avoid memory allocations without being informed about the workload to be performed. Thanks, Horia
