All of lore.kernel.org
 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

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.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
Subject: Re: [f2fs-dev] [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


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

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

Thread overview: 31+ 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 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-08-21  7:57 ` [PATCH v4 1/8] block: Keyslot Manager for Inline Encryption Satya Tangirala
2019-08-21  7:57   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-08-27 20:49   ` Eric Biggers
2019-08-27 21:15   ` Eric Biggers
2019-08-27 21:15     ` [f2fs-dev] " Eric Biggers
2019-08-21  7:57 ` [PATCH v4 2/8] block: Add encryption context to struct bio Satya Tangirala
2019-08-21  7:57   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-09-24 10:57   ` Stanley Chu
2019-09-24 10:57     ` [f2fs-dev] " Stanley Chu
2019-08-21  7:57 ` [PATCH v4 3/8] block: blk-crypto for Inline Encryption Satya Tangirala
2019-08-21  7:57   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-08-26 18:17   ` Jonathan Corbet
2019-08-26 18:17     ` [f2fs-dev] " Jonathan Corbet
2019-08-27 22:34   ` Eric Biggers
2019-08-27 22:34     ` [f2fs-dev] " 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   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-08-21  7:57 ` [PATCH v4 5/8] scsi: ufs: UFS crypto API Satya Tangirala
2019-08-21  7:57   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-08-27 23:25   ` Eric Biggers [this message]
2019-08-27 23:25     ` Eric Biggers
2019-08-21  7:57 ` [PATCH v4 6/8] scsi: ufs: Add inline encryption support to UFS Satya Tangirala
2019-08-21  7:57   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-08-21  7:57 ` [PATCH v4 7/8] fscrypt: wire up fscrypt to use blk-crypto Satya Tangirala
2019-08-21  7:57   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2019-08-28  0:07   ` Eric Biggers
2019-08-28  0:07     ` [f2fs-dev] " Eric Biggers
2019-08-21  7:57 ` [PATCH v4 8/8] f2fs: Wire up f2fs to use inline encryption via fscrypt Satya Tangirala
2019-08-21  7:57   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel

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 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.