All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Eric Biggers <ebiggers@kernel.org>,
	Satya Tangirala <satyat@google.com>,
	linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-ext4@vger.kernel.org,
	Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
	Kuohong Wang <kuohong.wang@mediatek.com>,
	Kim Boojin <boojin.kim@samsung.com>
Subject: Re: [PATCH v13 00/12] Inline Encryption Support
Date: Fri, 15 May 2020 00:41:27 -0700	[thread overview]
Message-ID: <20200515074127.GA13926@infradead.org> (raw)
In-Reply-To: <8fa1aafe-1725-e586-ede3-a3273e674470@kernel.dk>

On Thu, May 14, 2020 at 09:48:40AM -0600, Jens Axboe wrote:
> I have applied 1-5 for 5.8. Small tweak needed in patch 3 due to a header
> inclusion, but clean apart from that.

I looked at this a bit more as it clashed with my outstanding
q_usage_counter optimization, and I think we should move the
blk_crypto_bio_prep call into blk-mq, similar to what we do about
the integrity_prep call.  Comments?

---
From b7a78be7de0f39ef972d6a2f97a3982a422bf3ab Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch@lst.de>
Date: Fri, 15 May 2020 09:32:40 +0200
Subject: block: move blk_crypto_bio_prep into blk_mq_make_request

Currently blk_crypto_bio_prep is called for every block driver, including
stacking drivers, which is probably not the right thing to do.  Instead
move it to blk_mq_make_request, similar to how we handle integrity data.
If we ever grow a low-level make_request based driver that wants
encryption it will have to call blk_crypto_bio_prep manually, but I really
hope we don't grow more non-stacking make_request drivers to start with.

This also means we only need to do the crypto preparation after splitting
and bouncing the bio, which means we don't bother allocating the fallback
context for a bio that might only be a dummy and gets split or bounced
later.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 block/blk-core.c | 13 +++++--------
 block/blk-mq.c   |  2 ++
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index 1e97f99735232..ac59afaa26960 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1131,12 +1131,10 @@ blk_qc_t generic_make_request(struct bio *bio)
 			/* Create a fresh bio_list for all subordinate requests */
 			bio_list_on_stack[1] = bio_list_on_stack[0];
 			bio_list_init(&bio_list_on_stack[0]);
-			if (blk_crypto_bio_prep(&bio)) {
-				if (q->make_request_fn)
-					ret = q->make_request_fn(q, bio);
-				else
-					ret = blk_mq_make_request(q, bio);
-			}
+			if (q->make_request_fn)
+				ret = q->make_request_fn(q, bio);
+			else
+				ret = blk_mq_make_request(q, bio);
 
 			blk_queue_exit(q);
 
@@ -1185,8 +1183,7 @@ blk_qc_t direct_make_request(struct bio *bio)
 		return BLK_QC_T_NONE;
 	if (unlikely(bio_queue_enter(bio)))
 		return BLK_QC_T_NONE;
-	if (blk_crypto_bio_prep(&bio))
-		ret = blk_mq_make_request(q, bio);
+	ret = blk_mq_make_request(q, bio);
 	blk_queue_exit(q);
 	return ret;
 }
diff --git a/block/blk-mq.c b/block/blk-mq.c
index d2962863e629f..0b5a0fa0d124b 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2033,6 +2033,8 @@ blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
 	blk_queue_bounce(q, &bio);
 	__blk_queue_split(q, &bio, &nr_segs);
 
+	if (!blk_crypto_bio_prep(&bio))
+		return BLK_QC_T_NONE;
 	if (!bio_integrity_prep(bio))
 		return BLK_QC_T_NONE;
 
-- 
2.26.2


WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-scsi@vger.kernel.org, Kim Boojin <boojin.kim@samsung.com>,
	Kuohong Wang <kuohong.wang@mediatek.com>,
	Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
	Satya Tangirala <satyat@google.com>,
	Eric Biggers <ebiggers@kernel.org>,
	linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH v13 00/12] Inline Encryption Support
Date: Fri, 15 May 2020 00:41:27 -0700	[thread overview]
Message-ID: <20200515074127.GA13926@infradead.org> (raw)
In-Reply-To: <8fa1aafe-1725-e586-ede3-a3273e674470@kernel.dk>

On Thu, May 14, 2020 at 09:48:40AM -0600, Jens Axboe wrote:
> I have applied 1-5 for 5.8. Small tweak needed in patch 3 due to a header
> inclusion, but clean apart from that.

I looked at this a bit more as it clashed with my outstanding
q_usage_counter optimization, and I think we should move the
blk_crypto_bio_prep call into blk-mq, similar to what we do about
the integrity_prep call.  Comments?

---
From b7a78be7de0f39ef972d6a2f97a3982a422bf3ab Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch@lst.de>
Date: Fri, 15 May 2020 09:32:40 +0200
Subject: block: move blk_crypto_bio_prep into blk_mq_make_request

Currently blk_crypto_bio_prep is called for every block driver, including
stacking drivers, which is probably not the right thing to do.  Instead
move it to blk_mq_make_request, similar to how we handle integrity data.
If we ever grow a low-level make_request based driver that wants
encryption it will have to call blk_crypto_bio_prep manually, but I really
hope we don't grow more non-stacking make_request drivers to start with.

This also means we only need to do the crypto preparation after splitting
and bouncing the bio, which means we don't bother allocating the fallback
context for a bio that might only be a dummy and gets split or bounced
later.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 block/blk-core.c | 13 +++++--------
 block/blk-mq.c   |  2 ++
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index 1e97f99735232..ac59afaa26960 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1131,12 +1131,10 @@ blk_qc_t generic_make_request(struct bio *bio)
 			/* Create a fresh bio_list for all subordinate requests */
 			bio_list_on_stack[1] = bio_list_on_stack[0];
 			bio_list_init(&bio_list_on_stack[0]);
-			if (blk_crypto_bio_prep(&bio)) {
-				if (q->make_request_fn)
-					ret = q->make_request_fn(q, bio);
-				else
-					ret = blk_mq_make_request(q, bio);
-			}
+			if (q->make_request_fn)
+				ret = q->make_request_fn(q, bio);
+			else
+				ret = blk_mq_make_request(q, bio);
 
 			blk_queue_exit(q);
 
@@ -1185,8 +1183,7 @@ blk_qc_t direct_make_request(struct bio *bio)
 		return BLK_QC_T_NONE;
 	if (unlikely(bio_queue_enter(bio)))
 		return BLK_QC_T_NONE;
-	if (blk_crypto_bio_prep(&bio))
-		ret = blk_mq_make_request(q, bio);
+	ret = blk_mq_make_request(q, bio);
 	blk_queue_exit(q);
 	return ret;
 }
diff --git a/block/blk-mq.c b/block/blk-mq.c
index d2962863e629f..0b5a0fa0d124b 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2033,6 +2033,8 @@ blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
 	blk_queue_bounce(q, &bio);
 	__blk_queue_split(q, &bio, &nr_segs);
 
+	if (!blk_crypto_bio_prep(&bio))
+		return BLK_QC_T_NONE;
 	if (!bio_integrity_prep(bio))
 		return BLK_QC_T_NONE;
 
-- 
2.26.2



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2020-05-15  7:41 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14  0:37 [PATCH v13 00/12] Inline Encryption Support Satya Tangirala
2020-05-14  0:37 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [PATCH v13 01/12] Documentation: Document the blk-crypto framework Satya Tangirala
2020-05-14  0:37   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [PATCH v13 02/12] block: Keyslot Manager for Inline Encryption Satya Tangirala
2020-05-14  0:37   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [PATCH v13 03/12] block: Inline encryption support for blk-mq Satya Tangirala
2020-05-14  0:37   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [PATCH v13 04/12] block: Make blk-integrity preclude hardware inline encryption Satya Tangirala
2020-05-14  0:37   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [PATCH v13 05/12] block: blk-crypto-fallback for Inline Encryption Satya Tangirala
2020-05-14  0:37   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [PATCH v13 06/12] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala
2020-05-14  0:37   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-15  3:55   ` Stanley Chu
2020-05-15  3:55     ` [f2fs-dev] " Stanley Chu
2020-05-14  0:37 ` [PATCH v13 07/12] scsi: ufs: UFS crypto API Satya Tangirala
2020-05-14  0:37   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-15  6:35   ` Stanley Chu
2020-05-15  6:35     ` [f2fs-dev] " Stanley Chu
2020-05-14  0:37 ` [PATCH v13 08/12] scsi: ufs: Add inline encryption support to UFS Satya Tangirala
2020-05-14  0:37   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-14  5:12   ` Eric Biggers
2020-05-14  5:12     ` [f2fs-dev] " Eric Biggers
2020-05-15  7:37   ` Stanley Chu
2020-05-15  7:37     ` [f2fs-dev] " Stanley Chu
2020-05-14  0:37 ` [PATCH v13 09/12] fs: introduce SB_INLINECRYPT Satya Tangirala
2020-05-14  0:37   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [PATCH v13 10/12] fscrypt: add inline encryption support Satya Tangirala
2020-05-14  0:37   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-28 21:54   ` Eric Biggers
2020-05-28 21:54     ` [f2fs-dev] " Eric Biggers
2020-06-03  2:07   ` Eric Biggers
2020-06-03  2:07     ` [f2fs-dev] " Eric Biggers
2020-05-14  0:37 ` [PATCH v13 11/12] f2fs: " Satya Tangirala
2020-05-14  0:37   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-14  0:37 ` [PATCH v13 12/12] ext4: " Satya Tangirala
2020-05-14  0:37   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-14  5:10 ` [PATCH v13 00/12] Inline Encryption Support Eric Biggers
2020-05-14  5:10   ` [f2fs-dev] " Eric Biggers
2020-05-14 15:48   ` Jens Axboe
2020-05-14 15:48     ` [f2fs-dev] " Jens Axboe
2020-05-15  7:41     ` Christoph Hellwig [this message]
2020-05-15  7:41       ` Christoph Hellwig
2020-05-15 12:25       ` Satya Tangirala
2020-05-15 12:25         ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-05-15 14:42         ` Christoph Hellwig
2020-05-15 14:42           ` [f2fs-dev] " Christoph Hellwig
2020-05-15 17:00           ` Eric Biggers
2020-05-15 17:00             ` [f2fs-dev] " Eric Biggers
2020-05-18 16:50             ` Christoph Hellwig
2020-05-18 16:50               ` [f2fs-dev] " Christoph Hellwig
2020-05-15  1:04   ` Martin K. Petersen
2020-05-15  1:04     ` [f2fs-dev] " Martin K. Petersen

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=20200515074127.GA13926@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=bmuthuku@qti.qualcomm.com \
    --cc=boojin.kim@samsung.com \
    --cc=ebiggers@kernel.org \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-scsi@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.