From: Josef Bacik <josef@toxicpanda.com>
To: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>,
Eric Biggers <ebiggers@kernel.org>, Chris Mason <clm@fb.com>,
David Sterba <dsterba@suse.com>,
linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH v2 03/14] fscrypt: adjust effective lblks based on extents
Date: Fri, 14 Jul 2023 14:13:58 -0400 [thread overview]
Message-ID: <20230714181358.GA510453@perftesting> (raw)
In-Reply-To: <d198508a448c08103691a1649b49edfa0d4eb98e.1688927487.git.sweettea-kernel@dorminy.me>
On Sun, Jul 09, 2023 at 02:53:36PM -0400, Sweet Tea Dorminy wrote:
> If a filesystem uses extent-based encryption, then the offset within a
> file is not a constant which can be used for calculating an IV.
> For instance, the same extent could be blocks 0-8 in one file, and
> blocks 100-108 in another file. Instead, the block offset within the
> extent must be used instead.
>
> Update all uses of logical block offset within the file to use logical
> block offset within the extent, if applicable.
>
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> ---
> fs/crypto/crypto.c | 3 ++-
> fs/crypto/inline_crypt.c | 24 +++++++++++++++++-------
> 2 files changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c
> index 1b7e375b1c6b..d75f1b3f5795 100644
> --- a/fs/crypto/crypto.c
> +++ b/fs/crypto/crypto.c
> @@ -107,8 +107,9 @@ int fscrypt_crypt_block(const struct inode *inode, fscrypt_direction_t rw,
> struct skcipher_request *req = NULL;
> DECLARE_CRYPTO_WAIT(wait);
> struct scatterlist dst, src;
> + u64 ci_offset = 0;
> struct fscrypt_info *ci =
> - fscrypt_get_lblk_info(inode, lblk_num, NULL, NULL);
> + fscrypt_get_lblk_info(inode, lblk_num, &ci_offset, NULL);
> struct crypto_skcipher *tfm = ci->ci_enc_key->tfm;
> int res = 0;
>
> diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c
> index 885a2ec3d711..b3e7a5291d22 100644
> --- a/fs/crypto/inline_crypt.c
> +++ b/fs/crypto/inline_crypt.c
> @@ -267,12 +267,15 @@ void fscrypt_set_bio_crypt_ctx(struct bio *bio, const struct inode *inode,
> {
> const struct fscrypt_info *ci;
> u64 dun[BLK_CRYPTO_DUN_ARRAY_SIZE];
> + u64 ci_offset = 0;
>
> if (!fscrypt_inode_uses_inline_crypto(inode))
> return;
> - ci = fscrypt_get_lblk_info(inode, first_lblk, NULL, NULL);
> + ci = fscrypt_get_lblk_info(inode, first_lblk, &ci_offset, NULL);
> + if (!ci)
> + return;
>
> - fscrypt_generate_dun(ci, first_lblk, dun);
> + fscrypt_generate_dun(ci, ci_offset, dun);
> bio_crypt_set_ctx(bio, ci->ci_enc_key->blk_key, dun, gfp_mask);
> }
> EXPORT_SYMBOL_GPL(fscrypt_set_bio_crypt_ctx);
> @@ -350,22 +353,23 @@ bool fscrypt_mergeable_bio(struct bio *bio, const struct inode *inode,
> const struct bio_crypt_ctx *bc = bio->bi_crypt_context;
> u64 next_dun[BLK_CRYPTO_DUN_ARRAY_SIZE];
> struct fscrypt_info *ci;
> + u64 ci_offset = 0;
>
> if (!!bc != fscrypt_inode_uses_inline_crypto(inode))
> return false;
> if (!bc)
> return true;
>
> - ci = fscrypt_get_lblk_info(inode, next_lblk, NULL, NULL);
> + ci = fscrypt_get_lblk_info(inode, next_lblk, &ci_offset, NULL);
> /*
> * Comparing the key pointers is good enough, as all I/O for each key
> * uses the same pointer. I.e., there's currently no need to support
> * merging requests where the keys are the same but the pointers differ.
> */
> - if (bc->bc_key != ci->ci_enc_key->blk_key)
> + if (!ci || bc->bc_key != ci->ci_enc_key->blk_key)
> return false;
>
This seems like an unrelated change, we weren't checking !ci before and the
behavior hasn't changed with the new code. Thanks,
Josef
next prev parent reply other threads:[~2023-07-14 18:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-09 18:53 [PATCH v2 00/14] fscrypt: add extent encryption Sweet Tea Dorminy
2023-07-09 18:53 ` [PATCH v2 01/14] fscrypt: factor helper for locking master key Sweet Tea Dorminy
2023-07-09 18:53 ` [PATCH v2 02/14] fscrypt: factor getting info for a specific block Sweet Tea Dorminy
2023-07-09 18:53 ` [PATCH v2 03/14] fscrypt: adjust effective lblks based on extents Sweet Tea Dorminy
2023-07-14 18:13 ` Josef Bacik [this message]
2023-07-09 18:53 ` [PATCH v2 04/14] fscrypt: add a super_block pointer to fscrypt_info Sweet Tea Dorminy
2023-07-09 18:53 ` [PATCH v2 05/14] fscrypt: setup leaf inodes for extent encryption Sweet Tea Dorminy
2023-07-14 18:16 ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 06/14] fscrypt: allow infos to be owned by extents Sweet Tea Dorminy
2023-07-09 18:53 ` [PATCH v2 07/14] fscrypt: notify per-extent infos if master key vanishes Sweet Tea Dorminy
2023-07-17 14:54 ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 08/14] fscrypt: use an optional ino equivalent for per-extent infos Sweet Tea Dorminy
2023-07-09 18:53 ` [PATCH v2 09/14] fscrypt: move function call warning of busy inodes Sweet Tea Dorminy
2023-07-17 14:59 ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 10/14] fscrypt: revamp key removal for extent encryption Sweet Tea Dorminy
2023-07-17 15:18 ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 11/14] fscrypt: add creation/usage/freeing of per-extent infos Sweet Tea Dorminy
2023-07-17 15:21 ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 12/14] fscrypt: allow load/save of extent contexts Sweet Tea Dorminy
2023-07-17 15:23 ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 13/14] fscrypt: save session key credentials for extent infos Sweet Tea Dorminy
2023-07-17 14:31 ` Josef Bacik
2023-07-09 18:53 ` [PATCH v2 14/14] fscrypt: update documentation for per-extent keys Sweet Tea Dorminy
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=20230714181358.GA510453@perftesting \
--to=josef@toxicpanda.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=sweettea-kernel@dorminy.me \
--cc=tytso@mit.edu \
/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.