From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
To: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
"Theodore Y . Ts'o" <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>,
kernel-team@meta.com, linux-btrfs@vger.kernel.org,
linux-fscrypt@vger.kernel.org, ebiggers@kernel.org,
ngompa13@gmail.com
Cc: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Subject: [RFC PATCH 00/13] fscrypt: add extent encryption
Date: Sat, 2 Sep 2023 01:54:18 -0400 [thread overview]
Message-ID: <cover.1693630890.git.sweettea-kernel@dorminy.me> (raw)
This is a replacement for the former changeset (previously v3). This
doesn't reflect all the smaller feedback on v3: it's an attempt to address
the major points of giving extents and inodes different objects, and to
clearly define lightweight and heavyweight extent contexts. Currently,
with minor changes to the btrfs patchset building on it, it passes
tests.
Hopefully I understood the proposed alternate design and this is indeed
more elegant, reviewable, and maintainable.
This applies atop [3], which itself is based on kdave/misc-next.
Changelog:
RFC:
- Split fscrypt_info into a general fscrypt_common_info, an
inode-specific fscrypt_info, and an extent-specific
fscrypt_extent_info. All external interfaces use either an inode or
extent specific structure; most internal functions handle the common
structure.
- Tried to fix up more places to refer to infos instead of inodes and
files.
- Changed to use lightweight extent contexts containing just a nonce,
and then a following change to do heavyweight extent contexts
identical to inode contexts, so they're easily comparable.
- Dropped factoring lock_master_key() and adding super block pointer to
fscrypt_info changes, as they didn't seem necessary.
- Temporarily dropped optimization where leaf inodes with extents don't
have on-disk fscrypt_contexts. It's a convenient optimization and
affects btrfs disk format, but it's not very big and not strictly
needed to check whether the new structural arrangement is better.
v3:
- Added four additional changes:
- soft-deleting keys that extent infos might later need to use, so
the behavior of an open file after key removal matches inode-based
fscrypt.
- a set of changes to allow asynchronous info freeing for extents,
necessary due to locking constraints in btrfs.
- https://lore.kernel.org/linux-fscrypt/cover.1691505882.git.sweettea-kernel@dorminy.me/
v2:
- https://lore.kernel.org/linux-fscrypt/cover.1688927487.git.sweettea-kernel@dorminy.me/T/#t
[3] https://lore.kernel.org/linux-fscrypt/cover.1691505830.git.sweettea-kernel@dorminy.me/
Sweet Tea Dorminy (13):
fscrypt: factor getting info for a specific block
fscrypt: adjust effective lblks based on extents
fscrypt: move function call warning of busy inodes
fscrypt: split fscrypt_info into general and inode specific parts
fscrypt: add creation/usage/freeing of per-extent infos
fscrypt: allow load/save of extent contexts
fscrypt: store full fscrypt_contexts for each extent
fscrypt: save session key credentials for extent infos
fscrypt: revamp key removal for extent encryption
fscrypt: allow multiple extents to reference one info
fscrypt: cache list of inlinecrypt devices
fscrypt: allow asynchronous info freeing
fscrypt: update documentation for per-extent keys
Documentation/filesystems/fscrypt.rst | 43 ++-
fs/crypto/crypto.c | 48 ++-
fs/crypto/fname.c | 13 +-
fs/crypto/fscrypt_private.h | 245 +++++++++---
fs/crypto/hooks.c | 6 +-
fs/crypto/inline_crypt.c | 93 +++--
fs/crypto/keyring.c | 110 +++---
fs/crypto/keysetup.c | 530 ++++++++++++++++++++------
fs/crypto/keysetup_v1.c | 77 ++--
fs/crypto/policy.c | 34 +-
include/linux/fscrypt.h | 60 +++
11 files changed, 919 insertions(+), 340 deletions(-)
base-commit: 764e1420e0806a3536b53b4c52c1b08ae8425f7e
--
2.41.0
next reply other threads:[~2023-09-02 5:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-02 5:54 Sweet Tea Dorminy [this message]
2023-09-02 5:54 ` [RFC PATCH 01/13] fscrypt: factor getting info for a specific block Sweet Tea Dorminy
2023-09-02 5:54 ` [RFC PATCH 02/13] fscrypt: adjust effective lblks based on extents Sweet Tea Dorminy
2023-09-02 5:54 ` [RFC PATCH 03/13] fscrypt: move function call warning of busy inodes Sweet Tea Dorminy
2023-09-02 5:54 ` [RFC PATCH 04/13] fscrypt: split fscrypt_info into general and inode specific parts Sweet Tea Dorminy
2023-09-02 5:54 ` [RFC PATCH 05/13] fscrypt: add creation/usage/freeing of per-extent infos Sweet Tea Dorminy
2023-09-02 5:54 ` [RFC PATCH 06/13] fscrypt: allow load/save of extent contexts Sweet Tea Dorminy
2023-09-02 5:54 ` [RFC PATCH 07/13] fscrypt: store full fscrypt_contexts for each extent Sweet Tea Dorminy
2023-09-05 22:10 ` Neal Gompa
2023-09-02 5:54 ` [RFC PATCH 08/13] fscrypt: save session key credentials for extent infos Sweet Tea Dorminy
2023-09-02 5:54 ` [RFC PATCH 09/13] fscrypt: revamp key removal for extent encryption Sweet Tea Dorminy
2023-09-02 5:54 ` [RFC PATCH 10/13] fscrypt: allow multiple extents to reference one info Sweet Tea Dorminy
2023-09-02 5:54 ` [RFC PATCH 11/13] fscrypt: cache list of inlinecrypt devices Sweet Tea Dorminy
2023-09-02 5:54 ` [RFC PATCH 12/13] fscrypt: allow asynchronous info freeing Sweet Tea Dorminy
2023-09-02 5:54 ` [RFC PATCH 13/13] fscrypt: update documentation for per-extent keys Sweet Tea Dorminy
2023-09-05 17:33 ` [RFC PATCH 00/13] fscrypt: add extent encryption Josef Bacik
2023-09-07 5:52 ` Eric Biggers
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=cover.1693630890.git.sweettea-kernel@dorminy.me \
--to=sweettea-kernel@dorminy.me \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=josef@toxicpanda.com \
--cc=kernel-team@meta.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=ngompa13@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox