[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