All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <clm@fb.com>
To: Johannes Thumshirn <jthumshirn@suse.de>
Cc: David Sterba <dsterba@suse.com>,
	Linux BTRFS Mailinglist <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 14/17] btrfs: directly call into crypto framework for checsumming
Date: Fri, 10 May 2019 13:45:47 +0000	[thread overview]
Message-ID: <18303EEF-24F1-40BB-9448-A55324AA119A@fb.com> (raw)
In-Reply-To: <20190510111547.15310-15-jthumshirn@suse.de>

On 10 May 2019, at 7:15, 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.

It has been a while since I dug through the cryptoapi internals.  I have 
one vague and somewhat unfounded concern, where we're defining the disk 
format to be whatever is returned from looking up sha256 or crc32c in 
the crypto tables.  I'm not really sure how to resolve this since we 
obviously don't want our own sha256 implementation.

I'm a little concerned about about btrfs_csum_data() and 
btrfs_csum_final() below.  We're using two different 
SHASH_DESC_ON_STACK() and then overwriting internals (shash_desc_ctx()) 
with the assumption that whatever we're doing is going to be the same as 
using the same shash_desc struct for both the update and final calls.  I 
think we should be either using or adding a helper to the crypto api for 
this.  We're digging too deep into cryptoapi private structs with the 
current usage.

Otherwise, thanks for doing this, it looks great overall.

-chris

>
> 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;
>  }
>
>  void btrfs_csum_final(struct btrfs_fs_info *fs_info, u32 crc, u8 
> *result)
>  {
> -	put_unaligned_le32(~crc, result);
> +	SHASH_DESC_ON_STACK(shash, fs_info->csum_shash);
> +	u32 *ctx = (u32 *)shash_desc_ctx(shash);
> +	int err;
> +
> +	shash->tfm = fs_info->csum_shash;
> +	shash->flags = 0;
> +	*ctx = crc;
> +
> +	err = crypto_shash_final(shash, result);
> +	ASSERT(err);
>  }
>
>  /*
> -- 
> 2.16.4

  reply	other threads:[~2019-05-10 13:46 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 [this message]
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
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=18303EEF-24F1-40BB-9448-A55324AA119A@fb.com \
    --to=clm@fb.com \
    --cc=dsterba@suse.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.