public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
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


             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