Hi Johan,
> Now that each HCI device has its own AES crypto context we don't need
> the one stored in the SMP data any more. This patch removes the variable
> from struct smp_chan and updates the SMP code to use the per-hdev crypto
> context.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@xxxxxxxxx>
> ---
> net/bluetooth/smp.c | 15 ++-------------
> net/bluetooth/smp.h | 1 -
> 2 files changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> index 5867c1c3f436..6dcb35640b6f 100644
> --- a/net/bluetooth/smp.c
> +++ b/net/bluetooth/smp.c
> @@ -413,21 +413,13 @@ static void confirm_work(struct work_struct *work)
> {
> struct smp_chan *smp = container_of(work, struct smp_chan, confirm);
> struct l2cap_conn *conn = smp->conn;
> - struct crypto_blkcipher *tfm;
> + struct crypto_blkcipher *tfm = conn->hcon->hdev->tfm_aes;
> struct smp_cmd_pairing_confirm cp;
> int ret;
> u8 res[16], reason;
>
> BT_DBG("conn %p", conn);
>
> - tfm = crypto_alloc_blkcipher("ecb(aes)", 0, CRYPTO_ALG_ASYNC);
> - if (IS_ERR(tfm)) {
> - reason = SMP_UNSPECIFIED;
> - goto error;
> - }
> -
> - smp->tfm = tfm;
> -
so I am curious now to what happens if we are running SMP and at the same time are doing RPA resolving. Can the same crypto context be used that way?
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
