From: Jens Axboe <axboe@kernel.dk>
To: 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
Cc: Kuohong Wang <kuohong.wang@mediatek.com>,
Ladvine D Almeida <ladvine.dalmeida@synopsys.com>,
Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Parshuram Raju Thombare <pthombar@cadence.com>
Subject: Re: [f2fs-dev] [PATCH 3/8] block: blk-crypto for Inline Encryption
Date: Fri, 2 Aug 2019 13:51:42 -0700 [thread overview]
Message-ID: <c5bffc1e-ce6a-0060-cf55-e3dc446d7049@kernel.dk> (raw)
In-Reply-To: <20190710225609.192252-4-satyat@google.com>
On 7/10/19 4:56 PM, Satya Tangirala wrote:
> We introduce blk-crypto, which manages programming keyslots for struct
> bios. With blk-crypto, filesystems only need to call bio_crypt_set_ctx with
> the encryption key, algorithm and data_unit_num; they don't have to worry
> about getting a keyslot for each encryption context, as blk-crypto handles
> that. Blk-crypto also makes it possible for layered devices like device
> mapper to make use of inline encryption hardware.
>
> Blk-crypto delegates crypto operations to inline encryption hardware when
> available, and also contains a software fallback to the kernel crypto API.
> For more details, refer to Documentation/block/blk-crypto.txt.
>
> Known issues:
> 1) We're allocating crypto_skcipher in blk_crypto_keyslot_program, which
> uses GFP_KERNEL to allocate memory, but this function is on the write
> path for IO - we need to add support for specifying a different flags
> to the crypto API.
That's a must-fix before merging, btw.
> @@ -1018,7 +1019,9 @@ 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]);
> - ret = q->make_request_fn(q, bio);
> +
> + if (!blk_crypto_submit_bio(&bio))
> + ret = q->make_request_fn(q, bio);
>
> blk_queue_exit(q);
Why isn't this just stacking the ->make_request_fn() instead? Then we
could get this out of the hot path.
--
Jens Axboe
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: 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
Cc: Parshuram Raju Thombare <pthombar@cadence.com>,
Ladvine D Almeida <ladvine.dalmeida@synopsys.com>,
Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
Kuohong Wang <kuohong.wang@mediatek.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 3/8] block: blk-crypto for Inline Encryption
Date: Fri, 2 Aug 2019 13:51:42 -0700 [thread overview]
Message-ID: <c5bffc1e-ce6a-0060-cf55-e3dc446d7049@kernel.dk> (raw)
In-Reply-To: <20190710225609.192252-4-satyat@google.com>
On 7/10/19 4:56 PM, Satya Tangirala wrote:
> We introduce blk-crypto, which manages programming keyslots for struct
> bios. With blk-crypto, filesystems only need to call bio_crypt_set_ctx with
> the encryption key, algorithm and data_unit_num; they don't have to worry
> about getting a keyslot for each encryption context, as blk-crypto handles
> that. Blk-crypto also makes it possible for layered devices like device
> mapper to make use of inline encryption hardware.
>
> Blk-crypto delegates crypto operations to inline encryption hardware when
> available, and also contains a software fallback to the kernel crypto API.
> For more details, refer to Documentation/block/blk-crypto.txt.
>
> Known issues:
> 1) We're allocating crypto_skcipher in blk_crypto_keyslot_program, which
> uses GFP_KERNEL to allocate memory, but this function is on the write
> path for IO - we need to add support for specifying a different flags
> to the crypto API.
That's a must-fix before merging, btw.
> @@ -1018,7 +1019,9 @@ 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]);
> - ret = q->make_request_fn(q, bio);
> +
> + if (!blk_crypto_submit_bio(&bio))
> + ret = q->make_request_fn(q, bio);
>
> blk_queue_exit(q);
Why isn't this just stacking the ->make_request_fn() instead? Then we
could get this out of the hot path.
--
Jens Axboe
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: 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
Cc: Kuohong Wang <kuohong.wang@mediatek.com>,
Ladvine D Almeida <ladvine.dalmeida@synopsys.com>,
Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Parshuram Raju Thombare <pthombar@cadence.com>
Subject: Re: [PATCH 3/8] block: blk-crypto for Inline Encryption
Date: Fri, 2 Aug 2019 13:51:42 -0700 [thread overview]
Message-ID: <c5bffc1e-ce6a-0060-cf55-e3dc446d7049@kernel.dk> (raw)
In-Reply-To: <20190710225609.192252-4-satyat@google.com>
On 7/10/19 4:56 PM, Satya Tangirala wrote:
> We introduce blk-crypto, which manages programming keyslots for struct
> bios. With blk-crypto, filesystems only need to call bio_crypt_set_ctx with
> the encryption key, algorithm and data_unit_num; they don't have to worry
> about getting a keyslot for each encryption context, as blk-crypto handles
> that. Blk-crypto also makes it possible for layered devices like device
> mapper to make use of inline encryption hardware.
>
> Blk-crypto delegates crypto operations to inline encryption hardware when
> available, and also contains a software fallback to the kernel crypto API.
> For more details, refer to Documentation/block/blk-crypto.txt.
>
> Known issues:
> 1) We're allocating crypto_skcipher in blk_crypto_keyslot_program, which
> uses GFP_KERNEL to allocate memory, but this function is on the write
> path for IO - we need to add support for specifying a different flags
> to the crypto API.
That's a must-fix before merging, btw.
> @@ -1018,7 +1019,9 @@ 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]);
> - ret = q->make_request_fn(q, bio);
> +
> + if (!blk_crypto_submit_bio(&bio))
> + ret = q->make_request_fn(q, bio);
>
> blk_queue_exit(q);
Why isn't this just stacking the ->make_request_fn() instead? Then we
could get this out of the hot path.
--
Jens Axboe
next prev parent reply other threads:[~2019-08-02 20:51 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-10 22:56 [PATCH v3 0/8] Inline Encryption Support Satya Tangirala
2019-07-10 22:56 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` [PATCH 1/8] block: Keyslot Manager for Inline Encryption Satya Tangirala
2019-07-10 22:56 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` [PATCH 2/8] block: Add encryption context to struct bio Satya Tangirala
2019-07-10 22:56 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` Satya Tangirala via Linux-f2fs-devel
2019-08-02 20:46 ` [f2fs-dev] " Jens Axboe
2019-08-02 20:46 ` Jens Axboe
2019-08-02 20:46 ` Jens Axboe
2019-07-10 22:56 ` [PATCH 3/8] block: blk-crypto for Inline Encryption Satya Tangirala
2019-07-10 22:56 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` Satya Tangirala via Linux-f2fs-devel
2019-07-11 5:47 ` Randy Dunlap
2019-07-11 5:47 ` [f2fs-dev] " Randy Dunlap
2019-07-11 5:47 ` Randy Dunlap
2019-07-15 15:40 ` Eric Biggers
2019-07-15 15:40 ` [f2fs-dev] " Eric Biggers
2019-07-15 15:40 ` Eric Biggers
2019-08-02 20:51 ` Jens Axboe [this message]
2019-08-02 20:51 ` Jens Axboe
2019-08-02 20:51 ` Jens Axboe
2019-07-10 22:56 ` [PATCH 4/8] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala
2019-07-10 22:56 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` [PATCH 5/8] scsi: ufs: UFS crypto API Satya Tangirala
2019-07-10 22:56 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` [PATCH 6/8] scsi: ufs: Add inline encryption support to UFS Satya Tangirala
2019-07-10 22:56 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` [PATCH 7/8] fscrypt: wire up fscrypt to use blk-crypto Satya Tangirala
2019-07-10 22:56 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` Satya Tangirala via Linux-f2fs-devel
2019-07-12 19:27 ` Eric Biggers
2019-07-12 19:27 ` [f2fs-dev] " Eric Biggers
2019-07-12 19:27 ` Eric Biggers
2019-07-10 22:56 ` [f2fs-dev] [PATCH 8/8] f2fs: Wire up f2fs to use inline encryption via fscrypt Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` Satya Tangirala via Linux-f2fs-devel
2019-07-10 22:56 ` Satya Tangirala
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=c5bffc1e-ce6a-0060-cf55-e3dc446d7049@kernel.dk \
--to=axboe@kernel.dk \
--cc=bmuthuku@qti.qualcomm.com \
--cc=gregkh@linuxfoundation.org \
--cc=kuohong.wang@mediatek.com \
--cc=ladvine.dalmeida@synopsys.com \
--cc=linux-block@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=pthombar@cadence.com \
--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.