linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Satya Tangirala <satyat@google.com>
Cc: 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,
	Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
	Kuohong Wang <kuohong.wang@mediatek.com>,
	Kim Boojin <boojin.kim@samsung.com>
Subject: Re: [PATCH v4 5/8] scsi: ufs: UFS crypto API
Date: Tue, 27 Aug 2019 16:25:52 -0700	[thread overview]
Message-ID: <20190827232550.GA92220@gmail.com> (raw)
In-Reply-To: <20190821075714.65140-6-satyat@google.com>

On Wed, Aug 21, 2019 at 12:57:11AM -0700, Satya Tangirala wrote:
> +static int ufshcd_crypto_cap_find(void *hba_p,
> +			   enum blk_crypto_mode_num crypto_mode,
> +			   unsigned int data_unit_size)
> +{
> +	struct ufs_hba *hba = hba_p;
> +	enum ufs_crypto_alg ufs_alg;
> +	u8 data_unit_mask;
> +	int cap_idx;
> +	enum ufs_crypto_key_size ufs_key_size;
> +	union ufs_crypto_cap_entry *ccap_array = hba->crypto_cap_array;
> +
> +	if (!ufshcd_hba_is_crypto_supported(hba))
> +		return -EINVAL;
> +
> +	switch (crypto_mode) {
> +	case BLK_ENCRYPTION_MODE_AES_256_XTS:
> +		ufs_alg = UFS_CRYPTO_ALG_AES_XTS;
> +		ufs_key_size = UFS_CRYPTO_KEY_SIZE_256;
> +		break;
> +	/*
> +	 * case BLK_CRYPTO_ALG_BITLOCKER_AES_CBC:
> +	 *	ufs_alg = UFS_CRYPTO_ALG_BITLOCKER_AES_CBC;
> +	 *	break;
> +	 * case BLK_CRYPTO_ALG_AES_ECB:
> +	 *	ufs_alg = UFS_CRYPTO_ALG_AES_ECB;
> +	 *	break;
> +	 * case BLK_CRYPTO_ALG_ESSIV_AES_CBC:
> +	 *	ufs_alg = UFS_CRYPTO_ALG_ESSIV_AES_CBC;
> +	 *	break;
> +	 */

Perhaps just delete this comment... the constants are already outdated.

> +	hba->crypto_cfgs =
> +		devm_kcalloc(hba->dev,
> +			     hba->crypto_capabilities.config_count + 1,
> +			     sizeof(hba->crypto_cfgs[0]),
> +			     GFP_KERNEL);

Can use NUM_KEYSLOTS(hba) here, to avoid hardcoding the awkward '+ 1' again.

> +void ufshcd_crypto_setup_rq_keyslot_manager(struct ufs_hba *hba,
> +					    struct request_queue *q)
> +{
> +	if (!ufshcd_hba_is_crypto_supported(hba))
> +		return;
> +
> +	if (q) {
> +		mutex_lock(&hba->ksm_lock);
> +		if (!hba->ksm) {
> +			hba->ksm = keyslot_manager_create(
> +				hba->crypto_capabilities.config_count + 1,
> +				&ufshcd_ksm_ops, hba);
> +			hba->ksm_num_refs = 0;

Same here.

> +		}
> +		hba->ksm_num_refs++;
> +		mutex_unlock(&hba->ksm_lock);
> +		q->ksm = hba->ksm;
> +	}
> +	/*
> +	 * If we fail we make it look like
> +	 * crypto is not supported, which will avoid issues
> +	 * with reset
> +	 */
> +	if (!q || !q->ksm) {
> +		ufshcd_crypto_disable(hba);
> +		hba->crypto_capabilities.reg_val = 0;
> +		devm_kfree(hba->dev, hba->crypto_cap_array);
> +		devm_kfree(hba->dev, hba->crypto_cfgs);
> +	}
> +}
> +
> +void ufshcd_crypto_destroy_rq_keyslot_manager(struct ufs_hba *hba,
> +					      struct request_queue *q)
> +{
> +	if (q && q->ksm) {
> +		q->ksm = NULL;
> +		mutex_lock(&hba->ksm_lock);
> +		hba->ksm_num_refs--;
> +		if (hba->ksm_num_refs == 0) {
> +			keyslot_manager_destroy(hba->ksm);
> +			hba->ksm = NULL;
> +		}
> +		mutex_unlock(&hba->ksm_lock);
> +	}
> +}

Why is the keyslot_manager reference counted?  Doesn't it live as long as the
individual devices do?  So, can't we just create the keyslot manager when the
ufs_hba is created, and destroy it when the ufs_hba is destroyed?  Then for each
device we'd just set 'q->ksm = hba->ksm;', with no refcounting needed.

- Eric

  reply	other threads:[~2019-08-27 23:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21  7:57 [PATCH v4 0/8] Inline Encryption Support Satya Tangirala
2019-08-21  7:57 ` [PATCH v4 1/8] block: Keyslot Manager for Inline Encryption Satya Tangirala
2019-08-27 21:15   ` Eric Biggers
2019-08-21  7:57 ` [PATCH v4 2/8] block: Add encryption context to struct bio Satya Tangirala
2019-09-24 10:57   ` Stanley Chu
2019-08-21  7:57 ` [PATCH v4 3/8] block: blk-crypto for Inline Encryption Satya Tangirala
2019-08-26 18:17   ` Jonathan Corbet
2019-08-27 22:34   ` Eric Biggers
2019-08-21  7:57 ` [PATCH v4 4/8] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala
2019-08-21  7:57 ` [PATCH v4 5/8] scsi: ufs: UFS crypto API Satya Tangirala
2019-08-27 23:25   ` Eric Biggers [this message]
2019-08-21  7:57 ` [PATCH v4 6/8] scsi: ufs: Add inline encryption support to UFS Satya Tangirala
2019-08-21  7:57 ` [PATCH v4 7/8] fscrypt: wire up fscrypt to use blk-crypto Satya Tangirala
2019-08-28  0:07   ` Eric Biggers
2019-08-21  7:57 ` [PATCH v4 8/8] f2fs: Wire up f2fs to use inline encryption via fscrypt 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=20190827232550.GA92220@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=bmuthuku@qti.qualcomm.com \
    --cc=boojin.kim@samsung.com \
    --cc=kuohong.wang@mediatek.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=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).