On Mon, May 13, 2019 at 03:01:11PM +0200, Johannes Thumshirn wrote:
> On Mon, May 13, 2019 at 03:00:03PM +0200, David Sterba wrote:
> > 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 <jthumsh...@suse.de>
> > > ---
> > > 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.
>
> well at least the crc3c2() call we use does nothing else (from
> lib/libcrc32c.c):
Oh I see, and we actually can't avoid the crypto api because we want to
let it select the implementation based on acceleration hw or use the
fallback. Ok then.
