Hi I wrote this directly to hvr quite some time ago, yet is seems to have gotten lost along the route. CryptoAPI lets you specify the amount whether or not it should use an "atomic" implementation of a cipher. The atomic version differs from the "normal" version in two points: - it has to be implemented is SW - it may not do any memory allocation which can fail I think the API should have room for a more fine-grained specification of atomicity. I would like to see a modification of find_cipher_by_name(), which would take a equivalent of GFP_* flag and return the cipher implementation which uses specified or more contrained allocation to work. The scenario is this: Let's suppose we have a filesystem which does per-file encryption. In order to prevent loops, the entire filesystem needs to do GFP_NOFS or stricter allocations in the write-out path. Since the writeout path includes CryptoAPI, the filesystem has to use atomic CryptoAPI cipher implementations. In my mind this is a serious misfeature, since filesystems will need to use preallocated pools for encryption, thus hindering parellelism, and won't be able to take advantage of crypto accelerators. Comments appreciated. -- Kind regards, Robert Varga ------------------------------------------------------------------------------ n@hq.sk http://hq.sk/~nite/gpgkey.txt Wanna make me happy? http://www.amazon.com/o/registry/18CYK97BPGHAV
Attachment:
pgp00044.pgp
Description: PGP signature
