linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Satya Tangirala <satyat@google.com>
Cc: linux-scsi@vger.kernel.org, Kim Boojin <boojin.kim@samsung.com>,
	Kuohong Wang <kuohong.wang@mediatek.com>,
	Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-block@vger.kernel.org, linux-fscrypt@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH v10 03/12] block: Inline encryption support for blk-mq
Date: Wed, 22 Apr 2020 02:35:02 -0700	[thread overview]
Message-ID: <20200422093502.GB12290@infradead.org> (raw)
In-Reply-To: <20200408035654.247908-4-satyat@google.com>

> +/**
> + * __blk_crypto_bio_prep - Prepare bio for inline encryption
> + *
> + * @bio_ptr: pointer to original bio pointer
> + *
> + * Succeeds if the bio doesn't have inline encryption enabled or if the bio
> + * crypt context provided for the bio is supported by the underlying device's
> + * inline encryption hardware. Ends the bio with error otherwise.
> + *
> + * Caller must ensure bio has bio_crypt_ctx.
> + *
> + * Return: true on success; false on error (and bio->bi_status will be set
> + *	   appropriately, and bio_endio() will have been called so bio
> + *	   submission should abort).
> + */
> +bool __blk_crypto_bio_prep(struct bio **bio_ptr)
> +{
> +	struct bio *bio = *bio_ptr;

Why is the bio passed by references?  As far as I can see it is never
changed.

> +
> +	/* Error if bio has no data. */
> +	if (WARN_ON_ONCE(!bio_has_data(bio)))
> +		goto fail;
> +
> +	if (!bio_crypt_check_alignment(bio))
> +		goto fail;
> +
> +	/*
> +	 * Success if device supports the encryption context, and blk-integrity
> +	 * isn't supported by device/is turned off.
> +	 */
> +	if (!blk_ksm_crypto_cfg_supported(bio->bi_disk->queue->ksm,
> +				&bio->bi_crypt_context->bc_key->crypto_cfg)) {

The indentation here looks odd.

> +		bio->bi_status = BLK_STS_NOTSUPP;
> +		goto fail;
> +	}
> +
> +	return true;
> +fail:
> +	bio_endio(*bio_ptr);

This seems to fail to set a status for the bio_has_data case,
and setting the status for bio_crypt_check_alignment should be moved
to here, where we also end the IO.

> + * __blk_crypto_rq_bio_prep - Prepare a request when its first bio is inserted
> + *
> + * @rq: The request to prepare
> + * @bio: The first bio being inserted into the request
> + *
> + * Frees the bio crypt context in the request's old rq->crypt_ctx, if any, and
> + * moves the bio crypt context of the bio into the request's rq->crypt_ctx.
> + */
> +void __blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio)
> +{
> +	mempool_free(rq->crypt_ctx, bio_crypt_ctx_pool);
> +	rq->crypt_ctx = bio->bi_crypt_context;
> +	bio->bi_crypt_context = NULL;
> +}

This seems to be called in case of the both the initial request
creation and merging a bio into the request (although only the
front merge and not the back merge, which seems weird).

But even then the behvior seems odd as bio->bi_crypt_context becomes
NULL as soon as the bio is attached to a request, which seems like
a somewhat dangerous condition.  Maybe it works, but is it really worth
saving a little memory?  Why not just propagate the context of the first
bio to the request, and free them when the bio is completed?

Why do we always take the context from the bio instead of keeping
the one in the request?  After all we merge the bio into the request.

> +void __blk_crypto_rq_prep_clone(struct request *dst, struct request *src)
> +{
> +	dst->crypt_ctx = src->crypt_ctx;

Probably worth just open coding in the only caller..

> +
> +/**
> + * __blk_crypto_insert_cloned_request - Prepare a cloned request to be inserted
> + *					into a request queue.
> + * @rq: the request being queued
> + *
> + * Return: BLK_STS_OK on success, nonzero on error.
> + */
> +blk_status_t __blk_crypto_insert_cloned_request(struct request *rq)
> +{
> +	return blk_crypto_init_request(rq);

Same.

>  	__blk_queue_split(q, &bio, &nr_segs);
> @@ -2011,6 +2015,15 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
>  
>  	blk_mq_bio_to_request(rq, bio, nr_segs);
>  
> +	ret = blk_crypto_init_request(rq);
> +	if (ret != BLK_STS_OK) {
> +		bio->bi_status = ret;
> +		bio_endio(bio);
> +		blk_mq_free_request(rq);
> +		return BLK_QC_T_NONE;
> +	}

Didn't Eric have a comment last round that we shoul dtry this before
attaching the bio to simplify error handling?

> +#define BLK_CRYPTO_DUN_ARRAY_SIZE	(BLK_CRYPTO_MAX_IV_SIZE/sizeof(u64))

Please use whitespace before and after operators.


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

  reply	other threads:[~2020-04-22  9:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-08  3:56 [f2fs-dev] [PATCH v10 00/12] Inline Encryption Support Satya Tangirala via Linux-f2fs-devel
2020-04-08  3:56 ` [f2fs-dev] [PATCH v10 01/12] Documentation: Document the blk-crypto framework Satya Tangirala via Linux-f2fs-devel
2020-04-08  3:56 ` [f2fs-dev] [PATCH v10 02/12] block: Keyslot Manager for Inline Encryption Satya Tangirala via Linux-f2fs-devel
2020-04-22  9:22   ` Christoph Hellwig
2020-04-28  2:14     ` Satya Tangirala via Linux-f2fs-devel
2020-04-28  2:46       ` Eric Biggers
2020-04-28  2:57         ` Eric Biggers
2020-04-28  5:19           ` Christoph Hellwig
2020-04-08  3:56 ` [f2fs-dev] [PATCH v10 03/12] block: Inline encryption support for blk-mq Satya Tangirala via Linux-f2fs-devel
2020-04-22  9:35   ` Christoph Hellwig [this message]
2020-04-28  2:54     ` Satya Tangirala via Linux-f2fs-devel
2020-04-28  5:21       ` Christoph Hellwig
2020-04-08  3:56 ` [f2fs-dev] [PATCH v10 04/12] block: Make blk-integrity preclude hardware inline encryption Satya Tangirala via Linux-f2fs-devel
2020-04-08  3:56 ` [f2fs-dev] [PATCH v10 05/12] block: blk-crypto-fallback for Inline Encryption Satya Tangirala via Linux-f2fs-devel
2020-04-22  9:37   ` Christoph Hellwig
2020-04-08  3:56 ` [f2fs-dev] [PATCH v10 06/12] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala via Linux-f2fs-devel
2020-04-08  3:56 ` [f2fs-dev] [PATCH v10 07/12] scsi: ufs: UFS crypto API Satya Tangirala via Linux-f2fs-devel
2020-04-08  3:56 ` [f2fs-dev] [PATCH v10 08/12] scsi: ufs: Add inline encryption support to UFS Satya Tangirala via Linux-f2fs-devel
2020-04-08  3:56 ` [f2fs-dev] [PATCH v10 09/12] fs: introduce SB_INLINECRYPT Satya Tangirala via Linux-f2fs-devel
2020-04-08  3:56 ` [f2fs-dev] [PATCH v10 10/12] fscrypt: add inline encryption support Satya Tangirala via Linux-f2fs-devel
2020-04-08  3:56 ` [f2fs-dev] [PATCH v10 11/12] f2fs: " Satya Tangirala via Linux-f2fs-devel
2020-04-08  3:56 ` [f2fs-dev] [PATCH v10 12/12] ext4: " Satya Tangirala via Linux-f2fs-devel
2020-04-08  4:18 ` [f2fs-dev] [PATCH v10 00/12] Inline Encryption Support Eric Biggers

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=20200422093502.GB12290@infradead.org \
    --to=hch@infradead.org \
    --cc=bmuthuku@qti.qualcomm.com \
    --cc=boojin.kim@samsung.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).