[dm-devel] [PATCH] dm: verity target
Will Drewry
wad at chromium.org
Thu Nov 10 14:42:54 UTC 2011
On Thu, Nov 10, 2011 at 1:44 AM, Steffen Klassert
<steffen.klassert at secunet.com> wrote:
> On Wed, Nov 09, 2011 at 09:18:10PM -0800, Mandeep Singh Baines wrote:
>>
>> + * TODO(wad): All hash storage memory is pre-allocated and freed once an
>> + * entire branch has been verified.
>> + */
>> +struct dm_bht {
>> + /* Configured values */
>> + int depth; /* Depth of the tree including the root */
>> + unsigned int block_count; /* Number of blocks hashed */
>> + unsigned int block_size; /* Size of a hash block */
>> + char hash_alg[CRYPTO_MAX_ALG_NAME];
>> + unsigned char salt[DM_BHT_SALT_SIZE];
>> +
>> + /* Computed values */
>> + unsigned int node_count; /* Data size (in hashes) for each entry */
>> + unsigned int node_count_shift; /* first bit set - 1 */
>> + /* There is one per CPU so that verified can be simultaneous. */
>> + struct hash_desc hash_desc[NR_CPUS]; /* Container for the hash alg */
>
> Please don't add a new user for the old hash interface. If the hashes can
> be done asynchronous you can use ahash, if not use shash. Both interfaces
> are reentrant, that's probaply what you want to have here. You don't
> need to have this in a per cpu manner.
I'll check out the two interfaces. I didn't realize hash_desc was
deprecated specifically in favor of one of the others. I'm interested
in seeing if it is possible to not keep a per-cpu desc though with the
other apis. We do this now to avoid contention across multiple kernel
threads on crypto operations sharing the hash_desc (e.g., by wrapping
it in a mutex).
Thanks!
More information about the dm-devel
mailing list