kernel/linux.git/Documentation/block, branch v6.19.11

Documentation: ublk: Separate UBLK_F_AUTO_BUF_REG fallback behavior sublists

2025-06-13T15:25:42+00:00

Stephen Rothwell reports htmldocs warning on ublk docs: Documentation/block/ublk.rst:414: ERROR: Unexpected indentation. [docutils] Fix the warning by separating sublists of auto buffer registration fallback behavior from their appropriate parent list item. Fixes: ff20c516485e ("ublk: document auto buffer registration(UBLK_F_AUTO_BUF_REG)") Reported-by: Stephen Rothwell Closes: https://lore.kernel.org/linux-next/20250612132638.193de386@canb.auug.org.au/ Signed-off-by: Bagas Sanjaya Link: https://lore.kernel.org/r/20250613023857.15971-1-bagasdotme@gmail.com Signed-off-by: Jens Axboe

ublk: document auto buffer registration(UBLK_F_AUTO_BUF_REG)

2025-06-11T12:41:55+00:00

Document recently merged feature auto buffer registration(UBLK_F_AUTO_BUF_REG). Cc: Caleb Sander Mateos Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250611085632.109719-1-ming.lei@redhat.com Signed-off-by: Jens Axboe

Documentation: ublk: document UBLK_F_PER_IO_DAEMON

2025-05-31T20:38:57+00:00

Explain the restrictions imposed on ublk servers in two cases: 1. When UBLK_F_PER_IO_DAEMON is set (current ublk_drv) 2. When UBLK_F_PER_IO_DAEMON is not set (legacy) Remove most references to per-queue daemons, as the new UBLK_F_PER_IO_DAEMON feature renders that concept obsolete. Signed-off-by: Uday Shankar Reviewed-by: Caleb Sander Mateos Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20250529-ublk_task_per_io-v8-9-e9d3b119336a@purestorage.com Signed-off-by: Jens Axboe

Documentation: ublk: remove dead footnote

2025-03-31T13:06:22+00:00

A previous commit removed the use of this footnote, delete it. Reported-by: Stephen Rothwell Fixes: 3fdf2ec7da1c ("Documentation: ublk: Drop Stefan Hajnoczi's message footnote") Signed-off-by: Jens Axboe

ublk: document zero copy feature

2025-03-28T22:15:43+00:00

Add words to explain how zero copy feature works, and why it has to be trusted for handling IO read command. Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250327095123.179113-8-ming.lei@redhat.com Signed-off-by: Jens Axboe

blk-crypto: add ioctls to create and prepare hardware-wrapped keys

2025-02-10T16:54:19+00:00

Until this point, the kernel can use hardware-wrapped keys to do encryption if userspace provides one -- specifically a key in ephemerally-wrapped form. However, no generic way has been provided for userspace to get such a key in the first place. Getting such a key is a two-step process. First, the key needs to be imported from a raw key or generated by the hardware, producing a key in long-term wrapped form. This happens once in the whole lifetime of the key. Second, the long-term wrapped key needs to be converted into ephemerally-wrapped form. This happens each time the key is "unlocked". In Android, these operations are supported in a generic way through KeyMint, a userspace abstraction layer. However, that method is Android-specific and can't be used on other Linux systems, may rely on proprietary libraries, and also misleads people into supporting KeyMint features like rollback resistance that make sense for other KeyMint keys but don't make sense for hardware-wrapped inline encryption keys. Therefore, this patch provides a generic kernel interface for these operations by introducing new block device ioctls: - BLKCRYPTOIMPORTKEY: convert a raw key to long-term wrapped form. - BLKCRYPTOGENERATEKEY: have the hardware generate a new key, then return it in long-term wrapped form. - BLKCRYPTOPREPAREKEY: convert a key from long-term wrapped form to ephemerally-wrapped form. These ioctls are implemented using new operations in blk_crypto_ll_ops. Signed-off-by: Eric Biggers Tested-by: Bartosz Golaszewski # sm8650 Link: https://lore.kernel.org/r/20250204060041.409950-4-ebiggers@kernel.org Signed-off-by: Jens Axboe

blk-crypto: add basic hardware-wrapped key support

2025-02-10T16:54:19+00:00

To prevent keys from being compromised if an attacker acquires read access to kernel memory, some inline encryption hardware can accept keys which are wrapped by a per-boot hardware-internal key. This avoids needing to keep the raw keys in kernel memory, without limiting the number of keys that can be used. Such hardware also supports deriving a "software secret" for cryptographic tasks that can't be handled by inline encryption; this is needed for fscrypt to work properly. To support this hardware, allow struct blk_crypto_key to represent a hardware-wrapped key as an alternative to a raw key, and make drivers set flags in struct blk_crypto_profile to indicate which types of keys they support. Also add the ->derive_sw_secret() low-level operation, which drivers supporting wrapped keys must implement. For more information, see the detailed documentation which this patch adds to Documentation/block/inline-encryption.rst. Signed-off-by: Eric Biggers Tested-by: Bartosz Golaszewski # sm8650 Link: https://lore.kernel.org/r/20250204060041.409950-2-ebiggers@kernel.org Signed-off-by: Jens Axboe

Documentation: ublk: Drop Stefan Hajnoczi's message footnote

2025-01-28T22:02:17+00:00

Sphinx reports unreferenced footnote warning pointing to ubd-control message by Stefan Hajnoczi: Documentation/block/ublk.rst:336: WARNING: Footnote [#] is not referenced. [ref.footnote] Drop the footnote to squash above warning. Signed-off-by: Bagas Sanjaya Fixes: 4093cb5a0634 ("ublk_drv: add mechanism for supporting unprivileged ublk device") Reviewed-by: Stefan Hajnoczi Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20250122143456.68867-3-bagasdotme@gmail.com

Documentation: ublk: document UBLK_F_USER_RECOVERY_FAIL_IO

2024-10-22T14:16:40+00:00

Signed-off-by: Uday Shankar Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20241007182419.3263186-6-ushankar@purestorage.com Signed-off-by: Jens Axboe

docs: block: Document support for read-only partition in cmdline part

2024-10-22T14:14:56+00:00

Document support for read-only partition in cmdline partition for block devices by appending "ro" after the (partition name). Signed-off-by: Christian Marangi Link: https://lore.kernel.org/r/20241002221306.4403-3-ansuelsmth@gmail.com Signed-off-by: Jens Axboe