Message ID | 20210604195900.2096121-8-satyat@google.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | ensure bios aren't split in middle of crypto data unit | expand |
On Fri, Jun 04, 2021 at 07:58:57PM +0000, Satya Tangirala wrote: > Handle any error from blk_ksm_register() in the callers. Previously, > the callers ignored the return value because blk_ksm_register() wouldn't > fail as long as the request_queue didn't have integrity support too, but > as this is no longer the case, it's safer for the callers to just handle > the return value appropriately. > > Signed-off-by: Satya Tangirala <satyat@google.com> > --- > drivers/mmc/core/crypto.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/core/crypto.c b/drivers/mmc/core/crypto.c > index 419a368f8402..cccd8c7d7e7a 100644 > --- a/drivers/mmc/core/crypto.c > +++ b/drivers/mmc/core/crypto.c > @@ -21,8 +21,17 @@ void mmc_crypto_set_initial_state(struct mmc_host *host) > > void mmc_crypto_setup_queue(struct request_queue *q, struct mmc_host *host) > { > - if (host->caps2 & MMC_CAP2_CRYPTO) > - blk_ksm_register(&host->ksm, q); > + if (host->caps2 & MMC_CAP2_CRYPTO) { > + /* > + * This WARN_ON should never trigger since &host->ksm won't be > + * "empty" (i.e. will support at least 1 crypto capability), an > + * MMC device's request queue doesn't support integrity, and > + * it also satisfies all the block layer constraints (i.e. > + * supports SG gaps, doesn't have chunk sectors, has a > + * sufficiently large supported max_segments per bio) > + */ > + WARN_ON(!blk_ksm_register(&host->ksm, q)); > + } > } There appear to be some MMC host drivers that set max_segments to 1, so this explanation may not hold. It may hold for every driver that actually supports crypto, though. - Eric
On Wed, Jun 16, 2021 at 08:25:19PM -0700, Eric Biggers wrote: > On Fri, Jun 04, 2021 at 07:58:57PM +0000, Satya Tangirala wrote: > > + /* > > + * This WARN_ON should never trigger since &host->ksm won't be > > + * "empty" (i.e. will support at least 1 crypto capability), an > > + * MMC device's request queue doesn't support integrity, and > > + * it also satisfies all the block layer constraints (i.e. > > + * supports SG gaps, doesn't have chunk sectors, has a > > + * sufficiently large supported max_segments per bio) > > + */ > > + WARN_ON(!blk_ksm_register(&host->ksm, q)); > > + } > > } > > There appear to be some MMC host drivers that set max_segments to 1, so this > explanation may not hold. It may hold for every driver that actually supports > crypto, though. Yeah, I think it does hold for every driver that actually supports crypto. I'll check this more carefully before sending out the next version. > > - Eric
diff --git a/drivers/mmc/core/crypto.c b/drivers/mmc/core/crypto.c index 419a368f8402..cccd8c7d7e7a 100644 --- a/drivers/mmc/core/crypto.c +++ b/drivers/mmc/core/crypto.c @@ -21,8 +21,17 @@ void mmc_crypto_set_initial_state(struct mmc_host *host) void mmc_crypto_setup_queue(struct request_queue *q, struct mmc_host *host) { - if (host->caps2 & MMC_CAP2_CRYPTO) - blk_ksm_register(&host->ksm, q); + if (host->caps2 & MMC_CAP2_CRYPTO) { + /* + * This WARN_ON should never trigger since &host->ksm won't be + * "empty" (i.e. will support at least 1 crypto capability), an + * MMC device's request queue doesn't support integrity, and + * it also satisfies all the block layer constraints (i.e. + * supports SG gaps, doesn't have chunk sectors, has a + * sufficiently large supported max_segments per bio) + */ + WARN_ON(!blk_ksm_register(&host->ksm, q)); + } } EXPORT_SYMBOL_GPL(mmc_crypto_setup_queue);
Handle any error from blk_ksm_register() in the callers. Previously, the callers ignored the return value because blk_ksm_register() wouldn't fail as long as the request_queue didn't have integrity support too, but as this is no longer the case, it's safer for the callers to just handle the return value appropriately. Signed-off-by: Satya Tangirala <satyat@google.com> --- drivers/mmc/core/crypto.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)