All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Bart Van Assche <bvanassche@acm.org>,
	Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org
Subject: Re: [PATCH v3 0/7] Fix bio splitting by the crypto fallback code
Date: Mon, 21 Jul 2025 08:01:24 +0200	[thread overview]
Message-ID: <20250721060124.GA28434@lst.de> (raw)
In-Reply-To: <20250718165024.GD1574@quark>

On Fri, Jul 18, 2025 at 09:50:24AM -0700, Eric Biggers wrote:
> But, as suggested at
> https://lore.kernel.org/linux-block/20250717044342.GA26995@lst.de/ it
> should also be okay to reorganize things so that the regular
> submit_bio() does not support the fallback, and upper layers have to
> call a different function blk_crypto_fallback_submit_bio() if they want
> the fallback.  I don't think that would help with the splitting issue
> directly,

It actually does.  Splitting before submit_bio will automatically
get the ordering right.  It is something done by a lot of file systems
already and trivially done.

> but perhaps we could make the filesystems just not submit bios
> that would need splitting by blk-crypto-fallback, which would solve the
> issue.

I think that distinction is a bit fuzzy.  When stacking the blk-crypto
fallback helpers above submit_bio, the split is formally done by the
file systems, just using generic library helpers.  As modern file systems
usually build bios to the full possibly size and then split them based
on limits I suspect that scheme is also the best here, but there might
be exceptions where just looking at the limits and not building the
bio bigger might be suitable, but I suspect they'd be the unusual
case.


  reply	other threads:[~2025-07-21  6:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-15 20:10 [PATCH v3 0/7] Fix bio splitting by the crypto fallback code Bart Van Assche
2025-07-15 20:10 ` [PATCH v3 1/7] block: Improve blk_crypto_fallback_split_bio_if_needed() Bart Van Assche
2025-07-16 11:49   ` John Garry
2025-07-16 17:20     ` Bart Van Assche
2025-07-15 20:10 ` [PATCH v3 2/7] block: Split blk_crypto_fallback_split_bio_if_needed() Bart Van Assche
2025-07-15 20:10 ` [PATCH v3 3/7] block: Modify the blk_crypto_bio_prep() calling convention Bart Van Assche
2025-07-15 20:10 ` [PATCH v3 4/7] block: Modify the blk_crypto_fallback_bio_prep() " Bart Van Assche
2025-07-15 20:10 ` [PATCH v3 5/7] block: Change the blk_crypto_fallback_encrypt_bio() " Bart Van Assche
2025-07-15 20:10 ` [PATCH v3 6/7] block: Rework splitting of encrypted bios Bart Van Assche
2025-07-15 20:10 ` [PATCH v3 7/7] block, crypto: Remove crypto_bio_split Bart Van Assche
2025-07-15 21:44 ` [PATCH v3 0/7] Fix bio splitting by the crypto fallback code Eric Biggers
2025-07-15 22:35   ` Bart Van Assche
2025-07-16  1:14     ` Eric Biggers
2025-07-16 11:25   ` Christoph Hellwig
2025-07-17  4:43   ` Christoph Hellwig
2025-07-17 17:58     ` Bart Van Assche
2025-07-18  8:17       ` Christoph Hellwig
2025-07-18 15:37     ` Bart Van Assche
2025-07-18 16:50       ` Eric Biggers
2025-07-21  6:01         ` Christoph Hellwig [this message]
2025-07-16 16:12 ` Bart Van Assche

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=20250721060124.GA28434@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=ebiggers@kernel.org \
    --cc=linux-block@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.