From: David Sterba <dsterba@suse.cz>
To: Johannes Thumshirn <jthumshirn@suse.de>
Cc: dsterba@suse.cz, Linux BTRFS Mailinglist <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 14/17] btrfs: directly call into crypto framework for checsumming
Date: Mon, 13 May 2019 16:30:59 +0200 [thread overview]
Message-ID: <20190513143059.GB3138@twin.jikos.cz> (raw)
In-Reply-To: <20190513130111.GD18838@x250.microfocus.com>
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@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.
next prev parent reply other threads:[~2019-05-13 14:30 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-10 11:15 [PATCH 00/17] Add support for SHA-256 checksums Johannes Thumshirn
2019-05-10 11:15 ` [PATCH 01/17] btrfs: use btrfs_csum_data() instead of directly calling crc32c Johannes Thumshirn
2019-05-10 16:16 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 02/17] btrfs: resurrect btrfs_crc32c() Johannes Thumshirn
2019-05-10 16:16 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 03/17] btrfs: use btrfs_crc32c() instead of btrfs_extref_hash() Johannes Thumshirn
2019-05-10 13:03 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 04/17] btrfs: use btrfs_crc32c() instead of btrfs_name_hash() Johannes Thumshirn
2019-05-10 12:56 ` Chris Mason
2019-05-13 7:04 ` Johannes Thumshirn
2019-05-10 11:15 ` [PATCH 05/17] btrfs: don't assume ordered sums to be 4 bytes Johannes Thumshirn
2019-05-10 13:25 ` Nikolay Borisov
2019-05-10 13:27 ` Nikolay Borisov
2019-05-13 7:06 ` Johannes Thumshirn
2019-05-10 11:15 ` [PATCH 06/17] btrfs: dont assume compressed_bio " Johannes Thumshirn
2019-05-10 11:15 ` [PATCH 07/17] btrfs: use btrfs_crc32c{,_final}() in for free space cache Johannes Thumshirn
2019-05-10 13:27 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 08/17] btrfs: format checksums according to type for printing Johannes Thumshirn
2019-05-10 13:28 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 09/17] btrfs: add common checksum type validation Johannes Thumshirn
2019-05-10 13:37 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 10/17] btrfs: check for supported superblock checksum type before checksum validation Johannes Thumshirn
2019-05-10 13:37 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 11/17] btrfs: Simplify btrfs_check_super_csum() and get rid of size assumptions Johannes Thumshirn
2019-05-10 13:41 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 12/17] btrfs: add boilerplate code for directly including the crypto framework Johannes Thumshirn
2019-05-10 16:28 ` Nikolay Borisov
2019-05-10 11:15 ` [PATCH 13/17] btrfs: pass in an fs_info to btrfs_csum_{data,final}() Johannes Thumshirn
2019-05-10 11:15 ` [PATCH 14/17] btrfs: directly call into crypto framework for checsumming Johannes Thumshirn
2019-05-10 13:45 ` Chris Mason
2019-05-10 13:54 ` Chris Mason
2019-05-13 7:17 ` Johannes Thumshirn
2019-05-13 13:55 ` Chris Mason
2019-05-14 12:46 ` Johannes Thumshirn
2019-05-13 13:00 ` David Sterba
2019-05-13 13:01 ` Johannes Thumshirn
2019-05-13 14:30 ` David Sterba [this message]
2019-05-10 11:15 ` [PATCH 15/17] btrfs: remove assumption about csum type form btrfs_csum_{data,final}() Johannes Thumshirn
2019-05-13 12:56 ` David Sterba
2019-05-10 11:15 ` [PATCH 16/17] btrfs: remove assumption about csum type form btrfs_print_data_csum_error() Johannes Thumshirn
2019-05-10 11:15 ` [PATCH 17/17] btrfs: add sha256 as another checksum algorithm Johannes Thumshirn
2019-05-10 12:30 ` Nikolay Borisov
2019-05-13 7:11 ` Johannes Thumshirn
2019-05-13 12:54 ` David Sterba
2019-05-13 12:55 ` Johannes Thumshirn
2019-05-15 1:45 ` Jeff Mahoney
2019-05-13 12:55 ` David Sterba
2019-05-13 12:58 ` Johannes Thumshirn
2019-05-15 17:27 ` [PATCH 00/17] Add support for SHA-256 checksums David Sterba
2019-05-16 6:30 ` Paul Jones
2019-05-16 8:16 ` Nikolay Borisov
2019-05-16 8:20 ` Johannes Thumshirn
2019-05-17 18:36 ` Diego Calleja
2019-05-17 19:07 ` Johannes Thumshirn
2019-05-18 0:38 ` Adam Borowski
2019-05-20 7:47 ` Johannes Thumshirn
2019-05-20 11:34 ` Austin S. Hemmelgarn
2019-05-20 11:57 ` Johannes Thumshirn
2019-05-20 11:42 ` Austin S. Hemmelgarn
2019-05-30 12:21 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190513143059.GB3138@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=jthumshirn@suse.de \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).