All of lore.kernel.org
 help / color / mirror / Atom feed
From: Satya Tangirala <satyaprateek2357@gmail.com>
To: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>, Eric Biggers <ebiggers@google.com>,
	Satya Tangirala <satyaprateek2357@gmail.com>,
	Satya Tangirala <satyat@google.com>
Subject: [PATCH v4 7/9] dm: handle error from blk_ksm_register()
Date: Tue,  6 Jul 2021 22:29:41 -0700	[thread overview]
Message-ID: <20210707052943.3960-8-satyaprateek2357@gmail.com> (raw)
In-Reply-To: <20210707052943.3960-1-satyaprateek2357@gmail.com>

From: Satya Tangirala <satyat@google.com>

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/md/dm-table.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 29cbfc3e3c4b..c79c0fbe80dd 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -1343,6 +1343,20 @@ static int dm_table_construct_keyslot_manager(struct dm_table *t)
 	 */
 	t->ksm = ksm;
 
+	/*
+	 * At this point, t->ksm is either NULL or *not* empty (i.e. will support
+	 * at least 1 crypto capability), the request queue doesn't support
+	 * integrity, and it also satisfies all the block layer constraints
+	 * "sufficiently" (as in the constraints of the DM device's request queue
+	 * won't preclude any of the intersection of the supported capabilities
+	 * of the underlying devices, since if some capability were precluded by
+	 * the DM device's request queue's constraints, that capability would
+	 * also have been precluded by one of the child device's request queues).
+	 *
+	 * Hence any future attempt to call blk_ksm_register() on t->ksm (if it's
+	 * not NULL) will succeed.
+	 */
+
 	return 0;
 }
 
@@ -1354,7 +1368,8 @@ static void dm_update_keyslot_manager(struct request_queue *q,
 
 	/* Make the ksm less restrictive */
 	if (!q->ksm) {
-		blk_ksm_register(t->ksm, q);
+		if (WARN_ON(!blk_ksm_register(t->ksm, q)))
+			dm_destroy_keyslot_manager(t->ksm);
 	} else {
 		blk_ksm_update_capabilities(q->ksm, t->ksm);
 		dm_destroy_keyslot_manager(t->ksm);
-- 
2.25.1


  parent reply	other threads:[~2021-07-07  5:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-07  5:29 [PATCH v4 0/9] ensure bios aren't split in middle of crypto data unit Satya Tangirala
2021-07-07  5:29 ` [PATCH v4 1/9] block: introduce blk_ksm_is_empty() Satya Tangirala
2021-07-23 16:45   ` Eric Biggers
2021-07-07  5:29 ` [PATCH v4 2/9] block: blk-crypto: introduce blk_crypto_bio_sectors_alignment() Satya Tangirala
2021-07-23 16:45   ` Eric Biggers
2021-07-07  5:29 ` [PATCH v4 3/9] block: introduce bio_required_sector_alignment() Satya Tangirala
2021-07-23 16:46   ` Eric Biggers
2021-07-07  5:29 ` [PATCH v4 4/9] block: keyslot-manager: introduce blk_ksm_restrict_dus_to_queue_limits() Satya Tangirala
2021-07-23 17:08   ` Eric Biggers
2021-07-07  5:29 ` [PATCH v4 5/9] ufshcd: handle error from blk_ksm_register() Satya Tangirala
2021-07-23 17:13   ` Eric Biggers
2021-07-07  5:29 ` [PATCH v4 6/9] mmc: " Satya Tangirala
2021-07-07  5:29 ` Satya Tangirala [this message]
2021-07-23 17:26   ` [PATCH v4 7/9] dm: " Eric Biggers
2021-07-07  5:29 ` [PATCH v4 8/9] blk-merge: Ensure bios aren't split in middle of a crypto data unit Satya Tangirala
2021-07-23 18:11   ` Eric Biggers
2021-07-07  5:29 ` [PATCH v4 9/9] block: add WARN_ON_ONCE() to bio_split() for sector alignment Satya Tangirala
2021-07-23 17:30   ` Eric Biggers
2021-07-23 16:49 ` [PATCH v4 0/9] ensure bios aren't split in middle of crypto data unit Eric Biggers
2021-07-23 17:52   ` Eric Biggers
2021-07-24  7:36 ` Christoph Hellwig

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=20210707052943.3960-8-satyaprateek2357@gmail.com \
    --to=satyaprateek2357@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=ebiggers@google.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=satyat@google.com \
    /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.