From: Eric Biggers <ebiggers@kernel.org>
To: linux-fscrypt@vger.kernel.org
Cc: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-doc@vger.kernel.org, Eric Biggers <ebiggers@kernel.org>
Subject: [PATCH 5/6] blk-crypto: Remove unused function blk_crypto_config_supported()
Date: Sat, 18 Jul 2026 14:46:54 -0700 [thread overview]
Message-ID: <20260718214655.63186-6-ebiggers@kernel.org> (raw)
In-Reply-To: <20260718214655.63186-1-ebiggers@kernel.org>
blk_crypto_config_supported() is no longer called, so remove it.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
Documentation/block/inline-encryption.rst | 29 ++++++++---------------
block/blk-crypto.c | 14 -----------
include/linux/blk-crypto.h | 2 --
3 files changed, 10 insertions(+), 35 deletions(-)
diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst
index cae23949a626..0052c7011b48 100644
--- a/Documentation/block/inline-encryption.rst
+++ b/Documentation/block/inline-encryption.rst
@@ -185,20 +185,12 @@ blk-crypto-fallback is optional and is controlled by the
API presented to users of the block layer
=========================================
-``blk_crypto_config_supported()`` allows users to check ahead of time whether
-inline encryption with particular crypto settings will work on a particular
-block_device -- either via hardware or via blk-crypto-fallback. This function
-takes in a ``struct blk_crypto_config`` which is like blk_crypto_key, but omits
-the actual bytes of the key and instead just contains the algorithm, data unit
-size, etc. This function can be useful if blk-crypto-fallback is disabled.
-
``blk_crypto_init_key()`` allows users to initialize a blk_crypto_key.
Users must call ``blk_crypto_start_using_key()`` before actually starting to use
-a blk_crypto_key on a block_device (even if ``blk_crypto_config_supported()``
-was called earlier). This is needed to initialize blk-crypto-fallback if it
-will be needed. This must not be called from the data path, as this may have to
-allocate resources, which may deadlock in that case.
+a blk_crypto_key on a block_device. This is needed to initialize
+blk-crypto-fallback if it will be needed. This must not be called from the data
+path, as this may have to allocate resources, which may deadlock in that case.
Next, to attach an encryption context to a bio, users should call
``bio_crypt_set_ctx()``. This function allocates a bio_crypt_ctx and attaches
@@ -220,16 +212,15 @@ any kernel data structures it may be linked into.
In summary, for users of the block layer, the lifecycle of a blk_crypto_key is
as follows:
-1. ``blk_crypto_config_supported()`` (optional)
-2. ``blk_crypto_init_key()``
-3. ``blk_crypto_start_using_key()``
-4. ``bio_crypt_set_ctx()`` (potentially many times)
-5. ``blk_crypto_evict_key()`` (after all I/O has completed)
-6. Zeroize the blk_crypto_key (this has no dedicated function)
+1. ``blk_crypto_init_key()``
+2. ``blk_crypto_start_using_key()``
+3. ``bio_crypt_set_ctx()`` (potentially many times)
+4. ``blk_crypto_evict_key()`` (after all I/O has completed)
+5. Zeroize the blk_crypto_key (this has no dedicated function)
If a blk_crypto_key is being used on multiple block_devices, then
-``blk_crypto_config_supported()`` (if used), ``blk_crypto_start_using_key()``,
-and ``blk_crypto_evict_key()`` must be called on each block_device.
+``blk_crypto_start_using_key()`` and ``blk_crypto_evict_key()`` must be called
+on each block_device.
API presented to device drivers
===============================
diff --git a/block/blk-crypto.c b/block/blk-crypto.c
index 0fe6ef0eea1d..bc3a9f59574b 100644
--- a/block/blk-crypto.c
+++ b/block/blk-crypto.c
@@ -386,20 +386,6 @@ bool blk_crypto_config_supported_natively(struct block_device *bdev,
return true;
}
-/*
- * Check if bios with @cfg can be en/decrypted by blk-crypto (i.e. either the
- * block_device it's submitted to supports inline crypto, or the
- * blk-crypto-fallback is enabled and supports the cfg).
- */
-bool blk_crypto_config_supported(struct block_device *bdev,
- const struct blk_crypto_config *cfg)
-{
- if (IS_ENABLED(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) &&
- cfg->key_type == BLK_CRYPTO_KEY_TYPE_RAW)
- return true;
- return blk_crypto_config_supported_natively(bdev, cfg);
-}
-
/**
* blk_crypto_start_using_key() - Start using a blk_crypto_key on a device
* @bdev: block device to operate on
diff --git a/include/linux/blk-crypto.h b/include/linux/blk-crypto.h
index 5f40821f99cd..938ff536838c 100644
--- a/include/linux/blk-crypto.h
+++ b/include/linux/blk-crypto.h
@@ -171,8 +171,6 @@ void blk_crypto_evict_key(struct block_device *bdev,
bool blk_crypto_config_supported_natively(struct block_device *bdev,
const struct blk_crypto_config *cfg);
-bool blk_crypto_config_supported(struct block_device *bdev,
- const struct blk_crypto_config *cfg);
int blk_crypto_derive_sw_secret(struct block_device *bdev,
const u8 *eph_key, size_t eph_key_size,
--
2.55.0
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: linux-fscrypt@vger.kernel.org
Cc: Eric Biggers <ebiggers@kernel.org>,
linux-doc@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-ext4@vger.kernel.org
Subject: [f2fs-dev] [PATCH 5/6] blk-crypto: Remove unused function blk_crypto_config_supported()
Date: Sat, 18 Jul 2026 14:46:54 -0700 [thread overview]
Message-ID: <20260718214655.63186-6-ebiggers@kernel.org> (raw)
In-Reply-To: <20260718214655.63186-1-ebiggers@kernel.org>
blk_crypto_config_supported() is no longer called, so remove it.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
Documentation/block/inline-encryption.rst | 29 ++++++++---------------
block/blk-crypto.c | 14 -----------
include/linux/blk-crypto.h | 2 --
3 files changed, 10 insertions(+), 35 deletions(-)
diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst
index cae23949a626..0052c7011b48 100644
--- a/Documentation/block/inline-encryption.rst
+++ b/Documentation/block/inline-encryption.rst
@@ -185,20 +185,12 @@ blk-crypto-fallback is optional and is controlled by the
API presented to users of the block layer
=========================================
-``blk_crypto_config_supported()`` allows users to check ahead of time whether
-inline encryption with particular crypto settings will work on a particular
-block_device -- either via hardware or via blk-crypto-fallback. This function
-takes in a ``struct blk_crypto_config`` which is like blk_crypto_key, but omits
-the actual bytes of the key and instead just contains the algorithm, data unit
-size, etc. This function can be useful if blk-crypto-fallback is disabled.
-
``blk_crypto_init_key()`` allows users to initialize a blk_crypto_key.
Users must call ``blk_crypto_start_using_key()`` before actually starting to use
-a blk_crypto_key on a block_device (even if ``blk_crypto_config_supported()``
-was called earlier). This is needed to initialize blk-crypto-fallback if it
-will be needed. This must not be called from the data path, as this may have to
-allocate resources, which may deadlock in that case.
+a blk_crypto_key on a block_device. This is needed to initialize
+blk-crypto-fallback if it will be needed. This must not be called from the data
+path, as this may have to allocate resources, which may deadlock in that case.
Next, to attach an encryption context to a bio, users should call
``bio_crypt_set_ctx()``. This function allocates a bio_crypt_ctx and attaches
@@ -220,16 +212,15 @@ any kernel data structures it may be linked into.
In summary, for users of the block layer, the lifecycle of a blk_crypto_key is
as follows:
-1. ``blk_crypto_config_supported()`` (optional)
-2. ``blk_crypto_init_key()``
-3. ``blk_crypto_start_using_key()``
-4. ``bio_crypt_set_ctx()`` (potentially many times)
-5. ``blk_crypto_evict_key()`` (after all I/O has completed)
-6. Zeroize the blk_crypto_key (this has no dedicated function)
+1. ``blk_crypto_init_key()``
+2. ``blk_crypto_start_using_key()``
+3. ``bio_crypt_set_ctx()`` (potentially many times)
+4. ``blk_crypto_evict_key()`` (after all I/O has completed)
+5. Zeroize the blk_crypto_key (this has no dedicated function)
If a blk_crypto_key is being used on multiple block_devices, then
-``blk_crypto_config_supported()`` (if used), ``blk_crypto_start_using_key()``,
-and ``blk_crypto_evict_key()`` must be called on each block_device.
+``blk_crypto_start_using_key()`` and ``blk_crypto_evict_key()`` must be called
+on each block_device.
API presented to device drivers
===============================
diff --git a/block/blk-crypto.c b/block/blk-crypto.c
index 0fe6ef0eea1d..bc3a9f59574b 100644
--- a/block/blk-crypto.c
+++ b/block/blk-crypto.c
@@ -386,20 +386,6 @@ bool blk_crypto_config_supported_natively(struct block_device *bdev,
return true;
}
-/*
- * Check if bios with @cfg can be en/decrypted by blk-crypto (i.e. either the
- * block_device it's submitted to supports inline crypto, or the
- * blk-crypto-fallback is enabled and supports the cfg).
- */
-bool blk_crypto_config_supported(struct block_device *bdev,
- const struct blk_crypto_config *cfg)
-{
- if (IS_ENABLED(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) &&
- cfg->key_type == BLK_CRYPTO_KEY_TYPE_RAW)
- return true;
- return blk_crypto_config_supported_natively(bdev, cfg);
-}
-
/**
* blk_crypto_start_using_key() - Start using a blk_crypto_key on a device
* @bdev: block device to operate on
diff --git a/include/linux/blk-crypto.h b/include/linux/blk-crypto.h
index 5f40821f99cd..938ff536838c 100644
--- a/include/linux/blk-crypto.h
+++ b/include/linux/blk-crypto.h
@@ -171,8 +171,6 @@ void blk_crypto_evict_key(struct block_device *bdev,
bool blk_crypto_config_supported_natively(struct block_device *bdev,
const struct blk_crypto_config *cfg);
-bool blk_crypto_config_supported(struct block_device *bdev,
- const struct blk_crypto_config *cfg);
int blk_crypto_derive_sw_secret(struct block_device *bdev,
const u8 *eph_key, size_t eph_key_size,
--
2.55.0
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2026-07-18 21:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-18 21:46 [PATCH 0/6] More fscrypt and blk-crypto doc updates and code removals Eric Biggers
2026-07-18 21:46 ` [f2fs-dev] " Eric Biggers via Linux-f2fs-devel
2026-07-18 21:46 ` [PATCH 1/6] fs: Update outdated comment for SB_INLINECRYPT Eric Biggers
2026-07-18 21:46 ` [f2fs-dev] " Eric Biggers via Linux-f2fs-devel
2026-07-18 21:46 ` [PATCH 2/6] f2fs: Update outdated comment in f2fs_write_begin() Eric Biggers
2026-07-18 21:46 ` [f2fs-dev] " Eric Biggers via Linux-f2fs-devel
2026-07-18 21:46 ` [PATCH 3/6] fscrypt: Remove unused function fscrypt_finalize_bounce_page() Eric Biggers
2026-07-18 21:46 ` [f2fs-dev] " Eric Biggers via Linux-f2fs-devel
2026-07-18 21:46 ` [PATCH 4/6] fscrypt: Update docs for data path Eric Biggers
2026-07-18 21:46 ` [f2fs-dev] " Eric Biggers via Linux-f2fs-devel
2026-07-18 21:46 ` Eric Biggers [this message]
2026-07-18 21:46 ` [f2fs-dev] [PATCH 5/6] blk-crypto: Remove unused function blk_crypto_config_supported() Eric Biggers via Linux-f2fs-devel
2026-07-18 21:46 ` [PATCH 6/6] blk-crypto: Update docs for blk-crypto-fallback motivation Eric Biggers
2026-07-18 21:46 ` [f2fs-dev] " Eric Biggers via Linux-f2fs-devel
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=20260718214655.63186-6-ebiggers@kernel.org \
--to=ebiggers@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@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.