From: Halil Pasic <pasic@linux.vnet.ibm.com>
To: Gonglei <arei.gonglei@huawei.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
linux-kernel@vger.kernel.org, qemu-devel@nongnu.org,
virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org,
linux-crypto@vger.kernel.org, luonengjun@huawei.com,
weidong.huang@huawei.com, wu.wubin@huawei.com,
xin.zeng@intel.com, claudio.fontana@huawei.com,
herbert@gondor.apana.org.au, davem@davemloft.net,
jianjay.zhou@huawei.com, hanweidong@huawei.com,
arei.gonglei@hotmail.com, cornelia.huck@de.ibm.com,
xuquan8@huawei.com, longpeng2@huawei.com,
salvatore.benedetto@intel.com
Subject: Re: [Qemu-devel] [PATCH v3] crypto: add virtio-crypto driver
Date: Mon, 28 Nov 2016 18:37:01 +0100 [thread overview]
Message-ID: <e49c3cba-2d34-d2d2-28f1-6e192d4ad6b1@linux.vnet.ibm.com> (raw)
In-Reply-To: <20161128185747-mutt-send-email-mst@kernel.org>
On 11/28/2016 06:19 PM, Michael S. Tsirkin wrote:
>>> +static int virtio_crypto_alg_ablkcipher_init_session(
>>> > > + struct virtio_crypto_ablkcipher_ctx *ctx,
>>> > > + uint32_t alg, const uint8_t *key,
>>> > > + unsigned int keylen,
>>> > > + int encrypt)
>>> > > +{
>>> > > + struct scatterlist outhdr, key_sg, inhdr, *sgs[3];
>>> > > + unsigned int tmp;
>>> > > + struct virtio_crypto *vcrypto = ctx->vcrypto;
>>> > > + int op = encrypt ? VIRTIO_CRYPTO_OP_ENCRYPT : VIRTIO_CRYPTO_OP_DECRYPT;
>>> > > + int err;
>>> > > + unsigned int num_out = 0, num_in = 0;
>>> > > +
>>> > > + /*
>>> > > + * Avoid to do DMA from the stack, switch to using
>>> > > + * dynamically-allocated for the key
>>> > > + */
>>> > > + uint8_t *cipher_key = kmalloc(keylen, GFP_ATOMIC);
>>> > > +
>>> > > + if (!cipher_key)
>>> > > + return -ENOMEM;
>>> > > +
>>> > > + memcpy(cipher_key, key, keylen);
>>> > > +
>>> > > + spin_lock(&vcrypto->ctrl_lock);
>>> > > + /* Pad ctrl header */
>>> > > + vcrypto->ctrl.header.opcode =
>>> > > + cpu_to_le32(VIRTIO_CRYPTO_CIPHER_CREATE_SESSION);
>>> > > + vcrypto->ctrl.header.algo = cpu_to_le32(alg);
>>> > > + /* Set the default dataqueue id to 0 */
>>> > > + vcrypto->ctrl.header.queue_id = 0;
>>> > > +
>>> > > + vcrypto->input.status = cpu_to_le32(VIRTIO_CRYPTO_ERR);
>>> > > + /* Pad cipher's parameters */
>>> > > + vcrypto->ctrl.u.sym_create_session.op_type =
>>> > > + cpu_to_le32(VIRTIO_CRYPTO_SYM_OP_CIPHER);
>>> > > + vcrypto->ctrl.u.sym_create_session.u.cipher.para.algo =
>>> > > + vcrypto->ctrl.header.algo;
>>> > > + vcrypto->ctrl.u.sym_create_session.u.cipher.para.keylen =
>>> > > + cpu_to_le32(keylen);
>>> > > + vcrypto->ctrl.u.sym_create_session.u.cipher.para.op =
>>> > > + cpu_to_le32(op);
>>> > > +
>>> > > + sg_init_one(&outhdr, &vcrypto->ctrl, sizeof(vcrypto->ctrl));
>>> > > + sgs[num_out++] = &outhdr;
>>> > > +
>>> > > + /* Set key */
>>> > > + sg_init_one(&key_sg, cipher_key, keylen);
>>> > > + sgs[num_out++] = &key_sg;
>>> > > +
>>> > > + /* Return status and session id back */
>>> > > + sg_init_one(&inhdr, &vcrypto->input, sizeof(vcrypto->input));
>>> > > + sgs[num_out + num_in++] = &inhdr;
>>> > > +
>>> > > + err = virtqueue_add_sgs(vcrypto->ctrl_vq, sgs, num_out,
>>> > > + num_in, vcrypto, GFP_ATOMIC);
>>> > > + if (err < 0) {
>>> > > + spin_unlock(&vcrypto->ctrl_lock);
>>> > > + kfree(cipher_key);
>>> > > + return err;
>>> > > + }
>>> > > + virtqueue_kick(vcrypto->ctrl_vq);
>>> > > +
>>> > > + /*
>>> > > + * Spin for a response, the kick causes an ioport write, trapping
>>> > > + * into the hypervisor, so the request should be handled immediately.
>>> > > + */
I have my doubts about this comment (and about the code below too). Is
'kick causes an ioport write' true for every transport/architecture?
If we relay on this property maybe the documentation of notify should
mention it.
I know we have the same message in virtio-net.
>>> > > + while (!virtqueue_get_buf(vcrypto->ctrl_vq, &tmp) &&
>>> > > + !virtqueue_is_broken(vcrypto->ctrl_vq))
>>> > > + cpu_relax();
> this spin under lock is kind of ugly.
> Why do we need to hold it while spinning?
> to prevent submitting more than one request?
> Isn't there a way to control this within crypto core?
>
> unlock
> relax
> lock
>
> would be better.
>
>>> > > +
>>> > > + if (le32_to_cpu(vcrypto->input.status) != VIRTIO_CRYPTO_OK) {
>>> > > + spin_unlock(&vcrypto->ctrl_lock);
>>> > > + pr_err("virtio_crypto: Create session failed status: %u\n",
>>> > > + le32_to_cpu(vcrypto->input.status));
>>> > > + kfree(cipher_key);
>>> > > + return -EINVAL;
>>> > > + }
>>> > > + spin_unlock(&vcrypto->ctrl_lock);
>>> > > +
> You drop lock here. If someone is trying to submit multiple
> requests, then the below will be racy as it might overwrite
> new result with previous data.
>
Was going to object on this too but Michael was faster.
Halil
>>> > > + spin_lock(&ctx->lock);
>>> > > + if (encrypt)
>>> > > + ctx->enc_sess_info.session_id =
>>> > > + le64_to_cpu(vcrypto->input.session_id);
>>> > > + else
>>> > > + ctx->dec_sess_info.session_id =
>>> > > + le64_to_cpu(vcrypto->input.session_id);
>>> > > + spin_unlock(&ctx->lock);
>>> > > +
>>> > > + kfree(cipher_key);
>>> > > + return 0;
>>> > > +}
>>> > > +
next prev parent reply other threads:[~2016-11-28 17:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-28 12:08 [Qemu-devel] [PATCH v3] virtio-crypto: add Linux driver Gonglei
2016-11-28 12:08 ` [Qemu-devel] [PATCH v3] crypto: add virtio-crypto driver Gonglei
2016-11-28 13:12 ` Cornelia Huck
2016-11-29 1:37 ` [Qemu-devel] [virtio-dev] " Gonglei (Arei)
2016-11-29 9:44 ` Cornelia Huck
2016-11-29 11:50 ` Gonglei (Arei)
2016-11-28 16:02 ` [Qemu-devel] " kbuild test robot
2016-11-28 16:20 ` Stefan Hajnoczi
2016-11-28 17:19 ` Michael S. Tsirkin
2016-11-28 17:37 ` Halil Pasic [this message]
2016-11-29 3:40 ` Gonglei (Arei)
2016-11-29 3:32 ` Gonglei (Arei)
2016-11-29 6:47 ` Gonglei (Arei)
2016-11-29 8:22 ` Gonglei (Arei)
2016-11-29 9:25 ` Stefan Hajnoczi
2016-11-29 9:29 ` Cornelia Huck
2016-11-29 11:46 ` Gonglei (Arei)
2016-11-29 9:31 ` Gonglei (Arei)
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=e49c3cba-2d34-d2d2-28f1-6e192d4ad6b1@linux.vnet.ibm.com \
--to=pasic@linux.vnet.ibm.com \
--cc=arei.gonglei@hotmail.com \
--cc=arei.gonglei@huawei.com \
--cc=claudio.fontana@huawei.com \
--cc=cornelia.huck@de.ibm.com \
--cc=davem@davemloft.net \
--cc=hanweidong@huawei.com \
--cc=herbert@gondor.apana.org.au \
--cc=jianjay.zhou@huawei.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longpeng2@huawei.com \
--cc=luonengjun@huawei.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=salvatore.benedetto@intel.com \
--cc=stefanha@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=weidong.huang@huawei.com \
--cc=wu.wubin@huawei.com \
--cc=xin.zeng@intel.com \
--cc=xuquan8@huawei.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).