qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"mreitz@redhat.com" <mreitz@redhat.com>,
	"kwolf@redhat.com" <kwolf@redhat.com>,
	Denis Lunev <den@virtuozzo.com>
Subject: Re: [Qemu-devel] [PATCH v2 5/5] crypto: support multiple threads accessing one QCryptoBlock
Date: Fri, 7 Dec 2018 09:45:38 +0000	[thread overview]
Message-ID: <20181207094538.GE13784@redhat.com> (raw)
In-Reply-To: <fa38eeb1-523f-0bbe-580c-c21a3b86ee21@virtuozzo.com>

On Thu, Dec 06, 2018 at 05:42:54PM +0000, Vladimir Sementsov-Ogievskiy wrote:
> 06.12.2018 13:54, Daniel P. Berrangé wrote:
> > On Wed, Dec 05, 2018 at 05:47:00PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> >> The two thing that should be handled are cipher and ivgen. For ivgen
> >> the solution is just mutex, as iv calculations should not be long in
> >> comparison with encryption/decryption. And for cipher let's just keep
> >> per-thread ciphers.
> >>
> >> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> >> ---
> 
> [..]
> 
> >> --- a/crypto/block.c
> >> +++ b/crypto/block.c
> 
> [..]
> 
> >>   static int do_qcrypto_cipher_encrypt(QCryptoCipher *cipher,
> >>                                        size_t niv,
> >>                                        QCryptoIVGen *ivgen,
> >> +                                     QemuMutex *ivgen_mutex,
> >>                                        int sectorsize,
> >>                                        uint64_t offset,
> >>                                        uint8_t *buf,
> >> @@ -218,10 +307,15 @@ static int do_qcrypto_cipher_encrypt(QCryptoCipher *cipher,
> >>       while (len > 0) {
> >>           size_t nbytes;
> >>           if (niv) {
> >> -            if (qcrypto_ivgen_calculate(ivgen,
> >> -                                        startsector,
> >> -                                        iv, niv,
> >> -                                        errp) < 0) {
> >> +            if (ivgen_mutex) {
> >> +                qemu_mutex_lock(ivgen_mutex);
> >> +            }
> >> +            ret = qcrypto_ivgen_calculate(ivgen, startsector, iv, niv, errp);
> >> +            if (ivgen_mutex) {
> >> +                qemu_mutex_unlock(ivgen_mutex);
> >> +            }
> > 
> > I think we should just make  ivgen_mutex compulsory....
> > 
> >> +
> >> +            if (ret < 0) {
> >>                   goto cleanup;
> >>               }
> >>   
> >> @@ -258,8 +352,9 @@ int qcrypto_cipher_decrypt_helper(QCryptoCipher *cipher,
> >>                                     size_t len,
> >>                                     Error **errp)
> >>   {
> >> -    return do_qcrypto_cipher_encrypt(cipher, niv, ivgen, sectorsize, offset,
> >> -                                     buf, len, qcrypto_cipher_decrypt, errp);
> >> +    return do_qcrypto_cipher_encrypt(cipher, niv, ivgen, NULL, sectorsize,
> >> +                                     offset, buf, len, qcrypto_cipher_decrypt,
> >> +                                     errp);
> >>   }
> >>   
> >>   
> >> @@ -272,11 +367,11 @@ int qcrypto_cipher_encrypt_helper(QCryptoCipher *cipher,
> >>                                     size_t len,
> >>                                     Error **errp)
> >>   {
> >> -    return do_qcrypto_cipher_encrypt(cipher, niv, ivgen, sectorsize, offset,
> >> -                                     buf, len, qcrypto_cipher_encrypt, errp);
> >> +    return do_qcrypto_cipher_encrypt(cipher, niv, ivgen, NULL, sectorsize,
> >> +                                     offset, buf, len, qcrypto_cipher_encrypt,
> >> +                                     errp);
> >>   }
> > 
> > ...and get the mutex passed into these functions, as its easier to just
> > know the ivgen is always protected, and not have to trace back the callpath
> > to see if the usage is safe.
> 
> but there places, where these helpers called without any QCryptoBlock, when we just
> have local cipher and ivgen, so there is no mutex and it's not needed.

Ah, ok.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  reply	other threads:[~2018-12-07  9:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-05 14:46 [Qemu-devel] [PATCH v2 0/5] crypto threads Vladimir Sementsov-Ogievskiy
2018-12-05 14:46 ` [Qemu-devel] [PATCH v2 1/5] crypto/block-luks: fix memory leak in qcrypto_block_luks_create Vladimir Sementsov-Ogievskiy
2018-12-06 10:34   ` Daniel P. Berrangé
2018-12-07 12:27   ` [Qemu-devel] [Qemu-block] " Alberto Garcia
2018-12-05 14:46 ` [Qemu-devel] [PATCH v2 2/5] crypto/block: refactor qcrypto_block_*crypt_helper functions Vladimir Sementsov-Ogievskiy
2018-12-06 10:36   ` Daniel P. Berrangé
2018-12-06 17:36     ` Vladimir Sementsov-Ogievskiy
2018-12-07  9:45       ` Daniel P. Berrangé
2018-12-07 12:37   ` [Qemu-devel] [Qemu-block] " Alberto Garcia
2018-12-05 14:46 ` [Qemu-devel] [PATCH v2 3/5] crypto/block: rename qcrypto_block_*crypt_helper Vladimir Sementsov-Ogievskiy
2018-12-06 10:39   ` Daniel P. Berrangé
2018-12-05 14:46 ` [Qemu-devel] [PATCH v2 4/5] crypto/block: introduce qcrypto_block_*crypt_helper functions Vladimir Sementsov-Ogievskiy
2018-12-06 10:39   ` Daniel P. Berrangé
2018-12-05 14:47 ` [Qemu-devel] [PATCH v2 5/5] crypto: support multiple threads accessing one QCryptoBlock Vladimir Sementsov-Ogievskiy
2018-12-06 10:54   ` Daniel P. Berrangé
2018-12-06 17:42     ` Vladimir Sementsov-Ogievskiy
2018-12-07  9:45       ` Daniel P. Berrangé [this message]
2018-12-07 14:44     ` Vladimir Sementsov-Ogievskiy
2018-12-07 14:45       ` Daniel P. Berrangé

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=20181207094538.GE13784@redhat.com \
    --to=berrange@redhat.com \
    --cc=den@virtuozzo.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.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).