From: Daniel Vacek <neelx@suse.com>
To: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
Eric Biggers <ebiggers@kernel.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>, Jens Axboe <axboe@kernel.dk>,
David Sterba <dsterba@suse.com>
Cc: linux-block@vger.kernel.org, Daniel Vacek <neelx@suse.com>,
linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v6 31/43] btrfs: limit encrypted writes to 256 segments
Date: Fri, 6 Feb 2026 19:23:03 +0100 [thread overview]
Message-ID: <20260206182336.1397715-32-neelx@suse.com> (raw)
In-Reply-To: <20260206182336.1397715-1-neelx@suse.com>
From: Josef Bacik <josef@toxicpanda.com>
For the fallback encrypted writes it allocates a bounce buffer to
encrypt, and if the bio is larger than 256 segments it splits the bio we
send down. This wreaks havoc on us because we need our actual original
bio to be passed into the process_cb callback in order to get at our
ordered extent. With the split we'll get some cloned bio that has none
of our information. Handle this by returning the length we need to be
truncated to and then splitting ourselves, which will handle giving us
the correct btrfs_bio that we need.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Daniel Vacek <neelx@suse.com>
---
v5: https://lore.kernel.org/linux-btrfs/1fc07b885453495bccea5a37e13d7d26333bd2af.1706116485.git.josef@toxicpanda.com/
* No changes since.
---
fs/btrfs/bio.c | 29 ++++++++++++++++++++++++++++-
fs/btrfs/fscrypt.c | 24 ++++++++++++++++++++++++
fs/btrfs/fscrypt.h | 6 ++++++
3 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/bio.c b/fs/btrfs/bio.c
index 487dd9267fd7..1ae81997fb2d 100644
--- a/fs/btrfs/bio.c
+++ b/fs/btrfs/bio.c
@@ -14,6 +14,7 @@
#include "zoned.h"
#include "file-item.h"
#include "raid-stripe-tree.h"
+#include "fscrypt.h"
static struct bio_set btrfs_bioset;
static struct bio_set btrfs_clone_bioset;
@@ -751,6 +752,7 @@ static bool btrfs_submit_chunk(struct btrfs_bio *bbio, int mirror_num)
u64 logical = bio->bi_iter.bi_sector << SECTOR_SHIFT;
u64 length = bio->bi_iter.bi_size;
u64 map_length = length;
+ u64 max_bio_len = length;
struct btrfs_io_context *bioc = NULL;
struct btrfs_io_stripe smap;
blk_status_t status;
@@ -762,6 +764,31 @@ static bool btrfs_submit_chunk(struct btrfs_bio *bbio, int mirror_num)
smap.rst_search_commit_root = false;
btrfs_bio_counter_inc_blocked(fs_info);
+
+ /*
+ * The blk-crypto-fallback limits bio sizes to 256 segments, because it
+ * has no way of controlling the pages it gets for the bounce bio it
+ * submits.
+ *
+ * If we don't pre-split our bio blk-crypto-fallback will do it for us,
+ * and then call into our checksum callback with a random cloned bio
+ * that isn't a btrfs_bio.
+ *
+ * To account for this we must truncate the bio ourselves, so we need to
+ * get our length at 256 segments and return that. We must do this
+ * before btrfs_map_block because the RAID5/6 code relies on having
+ * properly stripe aligned things, so we return the truncated length
+ * here so that btrfs_map_block() does the correct thing. Further down
+ * we actually truncate map_length to map_bio_len because map_length
+ * will be set to whatever the mapping length is for the underlying
+ * geometry. This will work properly with RAID5/6 as it will have
+ * already setup everything for the expected length, and everything else
+ * can handle with a truncated map_length.
+ */
+ if (bio_has_crypt_ctx(bio))
+ max_bio_len = btrfs_fscrypt_bio_length(bio, map_length);
+
+ map_length = max_bio_len;
ret = btrfs_map_block(fs_info, btrfs_op(bio), logical, &map_length,
&bioc, &smap, &mirror_num);
if (ret) {
@@ -780,7 +807,7 @@ static bool btrfs_submit_chunk(struct btrfs_bio *bbio, int mirror_num)
bbio->can_use_append = btrfs_use_zone_append(bbio);
- map_length = min(map_length, length);
+ map_length = min(map_length, max_bio_len);
if (bbio->can_use_append)
map_length = btrfs_append_map_length(bbio, map_length);
diff --git a/fs/btrfs/fscrypt.c b/fs/btrfs/fscrypt.c
index f4d6979a581b..b6350b043994 100644
--- a/fs/btrfs/fscrypt.c
+++ b/fs/btrfs/fscrypt.c
@@ -328,6 +328,30 @@ bool btrfs_mergeable_encrypted_bio(struct bio *bio, struct inode *inode,
return fscrypt_mergeable_extent_bio(bio, fi, logical_offset);
}
+/*
+ * The block crypto stuff allocates bounce buffers for encryption, so splits at
+ * BIO_MAX_VECS worth of segments. If we are larger than that number of
+ * segments then we need to limit the size to the size that BIO_MAX_VECS covers.
+ */
+int btrfs_fscrypt_bio_length(struct bio *bio, u64 map_length)
+{
+ unsigned int i = 0;
+ struct bio_vec bv;
+ struct bvec_iter iter;
+ u64 segments_length = 0;
+
+ if (bio_op(bio) != REQ_OP_WRITE)
+ return map_length;
+
+ bio_for_each_segment(bv, bio, iter) {
+ segments_length += bv.bv_len;
+ if (++i == BIO_MAX_VECS)
+ return segments_length;
+ }
+
+ return map_length;
+}
+
const struct fscrypt_operations btrfs_fscrypt_ops = {
.inode_info_offs = (int)offsetof(struct btrfs_inode, i_crypt_info) -
(int)offsetof(struct btrfs_inode, vfs_inode),
diff --git a/fs/btrfs/fscrypt.h b/fs/btrfs/fscrypt.h
index 1a2a4ffee383..347b34f45715 100644
--- a/fs/btrfs/fscrypt.h
+++ b/fs/btrfs/fscrypt.h
@@ -31,6 +31,7 @@ void btrfs_set_bio_crypt_ctx_from_extent(struct bio *bio,
bool btrfs_mergeable_encrypted_bio(struct bio *bio, struct inode *inode,
struct fscrypt_extent_info *fi,
u64 logical_offset);
+int btrfs_fscrypt_bio_length(struct bio *bio, u64 map_length);
#else
static inline void btrfs_fscrypt_save_extent_info(struct btrfs_path *path,
@@ -85,6 +86,11 @@ static inline bool btrfs_mergeable_encrypted_bio(struct bio *bio,
return true;
}
+static inline u64 btrfs_fscrypt_bio_length(struct bio *bio, u64 map_length)
+{
+ return map_length;
+}
+
#endif /* CONFIG_FS_ENCRYPTION */
extern const struct fscrypt_operations btrfs_fscrypt_ops;
--
2.51.0
next prev parent reply other threads:[~2026-02-06 18:25 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 18:22 [PATCH v6 00/43] btrfs: add fscrypt support Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 01/43] fscrypt: add per-extent encryption support Daniel Vacek
2026-02-21 22:11 ` Eric Biggers
2026-02-06 18:22 ` [PATCH v6 02/43] fscrypt: allow inline encryption for extent based encryption Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 03/43] fscrypt: add a __fscrypt_file_open helper Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 04/43] fscrypt: conditionally don't wipe mk secret until the last active user is done Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 05/43] blk-crypto: add a process_bio callback Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 06/43] fscrypt: add a process_bio hook to fscrypt_operations Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 07/43] fscrypt: expose fscrypt_nokey_name Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 08/43] fscrypt: add documentation about extent encryption Daniel Vacek
2026-02-06 18:43 ` Randy Dunlap
2026-02-17 14:48 ` Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 09/43] btrfs: add infrastructure for safe em freeing Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 10/43] btrfs: start using fscrypt hooks Daniel Vacek
2026-02-08 15:44 ` Chris Mason
2026-02-17 15:26 ` Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 11/43] btrfs: add inode encryption contexts Daniel Vacek
2026-02-08 15:36 ` Chris Mason
2026-02-18 13:18 ` Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 12/43] btrfs: add new FEATURE_INCOMPAT_ENCRYPT flag Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 13/43] btrfs: adapt readdir for encrypted and nokey names Daniel Vacek
2026-02-08 15:35 ` Chris Mason
2026-02-18 14:05 ` Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 14/43] btrfs: handle " Daniel Vacek
2026-02-08 15:28 ` Chris Mason
2026-02-18 14:50 ` Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 15/43] btrfs: implement fscrypt ioctls Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 16/43] btrfs: select encryption dependencies if FS_ENCRYPTION Daniel Vacek
2026-02-08 15:22 ` Chris Mason
2026-02-18 15:02 ` Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 17/43] btrfs: add get_devices hook for fscrypt Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 18/43] btrfs: set file extent encryption excplicitly Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 19/43] btrfs: add fscrypt_info and encryption_type to extent_map Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 20/43] btrfs: add fscrypt_info and encryption_type to ordered_extent Daniel Vacek
2026-02-08 15:18 ` Chris Mason
2026-02-18 15:29 ` Daniel Vacek
2026-02-18 15:50 ` Chris Mason
2026-02-18 16:11 ` Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 21/43] btrfs: plumb through setting the fscrypt_info for ordered extents Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 22/43] btrfs: populate the ordered_extent with the fscrypt context Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 23/43] btrfs: keep track of fscrypt info and orig_start for dio reads Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 24/43] btrfs: add extent encryption context tree item type Daniel Vacek
2026-02-08 15:16 ` Chris Mason
2026-02-18 17:25 ` Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 25/43] btrfs: pass through fscrypt_extent_info to the file extent helpers Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 26/43] btrfs: implement the fscrypt extent encryption hooks Daniel Vacek
2026-02-06 18:22 ` [PATCH v6 27/43] btrfs: setup fscrypt_extent_info for new extents Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 28/43] btrfs: populate ordered_extent with the orig offset Daniel Vacek
2026-02-08 15:12 ` Chris Mason
2026-03-03 13:42 ` Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 29/43] btrfs: set the bio fscrypt context when applicable Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 30/43] btrfs: add a bio argument to btrfs_csum_one_bio Daniel Vacek
2026-02-06 18:23 ` Daniel Vacek [this message]
2026-02-06 18:23 ` [PATCH v6 32/43] btrfs: implement process_bio cb for fscrypt Daniel Vacek
2026-02-08 15:10 ` Chris Mason
2026-03-24 9:36 ` Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 33/43] btrfs: implement read repair for encryption Daniel Vacek
2026-02-08 15:08 ` Chris Mason
2026-03-25 14:17 ` Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 34/43] btrfs: add test_dummy_encryption support Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 35/43] btrfs: make btrfs_ref_to_path handle encrypted filenames Daniel Vacek
2026-02-08 15:02 ` Chris Mason
2026-03-25 15:27 ` Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 36/43] btrfs: deal with encrypted symlinks in send Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 37/43] btrfs: decrypt file names for send Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 38/43] btrfs: load the inode context before sending writes Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 39/43] btrfs: set the appropriate free space settings in reconfigure Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 40/43] btrfs: support encryption with log replay Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 41/43] btrfs: disable auto defrag on encrypted files Daniel Vacek
2026-02-06 18:23 ` [PATCH v6 42/43] btrfs: disable encryption on RAID5/6 Daniel Vacek
2026-02-08 13:14 ` Chris Mason
2026-02-06 18:23 ` [PATCH v6 43/43] btrfs: disable send if we have encryption enabled Daniel Vacek
2026-02-06 18:42 ` [PATCH v6 00/43] btrfs: add fscrypt support Daniel Vacek
2026-02-21 20:56 ` Eric Biggers
2026-02-27 15:50 ` Daniel Vacek
2026-02-27 22:26 ` Neal Gompa
2026-02-28 7:57 ` Daniel Vacek
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=20260206182336.1397715-32-neelx@suse.com \
--to=neelx@suse.com \
--cc=axboe@kernel.dk \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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