Re: [PATCH 14/17] btrfs: directly call into crypto framework for checsumming

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <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.
> 
> 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.



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux