blk_crypto_f...ack_bio_prep(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… blk_crypto_fallback_bio_prep(9) πŸ’…

okay bestie, welcome to the Kernel API Manual β€” yes this is a real manpage and yes it's about making encrypted block I/O work when the hardware won't do it for you. buckle up πŸŽ€


✨ NAME ✨

blk_crypto_fallback_bio_prep β€” prep a bio so it can use fallback en/decryption πŸ¦‹


🌸 SYNOPSIS 🌸

bool blk_crypto_fallback_bio_prep (struct bio *bio );

πŸ’– ARGUMENTS πŸ’–

  • bio β€” the bio you're prepping, that's literally it, that's the whole argument 🫢

πŸ”₯ DESCRIPTION πŸ”₯

so here's the tea β˜• β€” what this function does depends on what your bio is up to:

  • if bio is doing a WRITE operation, it allocates one or more bios to contain the encrypted payload and submits them. slay, encrypted, submitted. πŸ’…
  • if it's a READ operation, it marks the bio for decryption by using bi_private and bi_end_io. that's the whole vibe check.

and in either case β€” write or read, doesn't matter, main character energy both ways β€” this function makes the submitted bio(s) look like regular bios for the purposes of the rest of the stack. like, as if no encryption context was ever specified, no cap. the one exception is blk-integrity β€” and heads up: blk-integrity and blk-crypto are not currently supported together 🫠 so don't try it.


⭐ RETURN ⭐

it returns true if bio should be submitted to the driver by the caller β€” otherwise false πŸ’€

and on error? it sets bio->bi_status, calls bio_endio, and returns false. so like, it handles its own drama before handing it back to you πŸ™ˆ


πŸ¦‹ SEE ALSO πŸ¦‹


aaaand that's the page, bestie πŸ’œ it lives in ./block and it's dated October 2026 β€” so it's from the future, iconic behavior honestly, periodt πŸŽ€βœ¨

πŸ“¦ where this page comes from