On Fri, May 10, 2019 at 01:15:44PM +0200, Johannes Thumshirn wrote:
> Currently btrfs_csum_data() relied on the crc32c() wrapper around the crypto
> framework for calculating the CRCs.
>
> As we have our own crypto_shash structure in the fs_info now, we can
> directly call into the crypto framework without going trough the wrapper.
>
> Signed-off-by: Johannes Thumshirn <jthumshirn@xxxxxxx>
> ---
> fs/btrfs/disk-io.c | 28 ++++++++++++++++++++++++++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index fb0b06b7b9f6..0c9ac7b45ce8 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -253,12 +253,36 @@ struct extent_map *btree_get_extent(struct btrfs_inode *inode,
> u32 btrfs_csum_data(struct btrfs_fs_info *fs_info, const char *data,
> u32 seed, size_t len)
> {
> - return crc32c(seed, data, len);
> + SHASH_DESC_ON_STACK(shash, fs_info->csum_shash);
> + u32 *ctx = (u32 *)shash_desc_ctx(shash);
> + u32 retval;
> + int err;
> +
> + shash->tfm = fs_info->csum_shash;
> + shash->flags = 0;
> + *ctx = seed;
> +
> + err = crypto_shash_update(shash, data, len);
> + ASSERT(err);
> +
> + retval = *ctx;
> + barrier_data(ctx);
> +
> + return retval;
I unfortunatelly had a dive into the crypto API calls and since then I'm
biased against using it (too much indirection and extra memory
references). So my idea of this function is:
switch (fs_info->csum_type) {
case CRC32:
... calculate crc32c;
break;
case SHA256:
... calculate sha56;
break;
}
with direct calls to the hash primitives rather than thravelling trough
the shash.
