Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1272973

Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure support

From Herbert Xu <herbert@gondor.apana.org.au>
Newsgroups linux.kernel
Subject Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure support
Date 2015-11-19 10:50 +0100
Message-ID <qwu0P-7xT-23@gated-at.bofh.it> (permalink)
References (5 earlier) <qvYX0-3RB-15@gated-at.bofh.it> <qw3ai-6MR-11@gated-at.bofh.it> <qwdjk-4US-11@gated-at.bofh.it> <qwl7c-1Xq-13@gated-at.bofh.it> <qwniG-3dU-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Nov 18, 2015 at 06:39:30PM -0800, Tim Chen wrote:
>
> The __cbc-aes-aesni-mb algorithm is marked as internal algorithm 
> with flag CRYPTO_ALG_INTERNAL, so it should not be picked up by other
> algorithms and should only be invoked from mcryptd.

OK I guess that's fine then.

> Anyway, I've udpated the aes_cbc_mb code with ablkcipher helper.
> So I will be posting the new series with ablkcipher walk
> after testing is done.

Yes I think what you have is a very special case.  As you said
the ablkcipher interface should be fairly low in overhead so I
think it makes sense to use that instead of blkcipher.

> The __sha1-mb works in tandem with the outer layer of mcryptd 
> aysnc algorithm. It does the completion for the outer 
> async algorithm.  So as far as mcryptd is concerned, the
> inner algorithm is synchronous in the sense that it is done
> once it dispatch the job to __sha1-mb and don't have to worry about it.
> I don't think mcryptd check for the return value from __sha1-mb
> so it should be okay to return 0 instead of -EINPROGRESS.  
> I'll double check that.

If it can never return EINPROGRESS then we should probably remove
the code in it that says "return -EINPROGRESS".

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure  support Herbert Xu <herbert@gondor.apana.org.au> - 2015-11-17 14:10 +0100
  Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure  support Tim Chen <tim.c.chen@linux.intel.com> - 2015-11-18 00:10 +0100
    Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure  support Herbert Xu <herbert@gondor.apana.org.au> - 2015-11-18 01:10 +0100
      Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure  support Tim Chen <tim.c.chen@linux.intel.com> - 2015-11-18 01:40 +0100
        Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure  support Herbert Xu <herbert@gondor.apana.org.au> - 2015-11-18 06:10 +0100
          Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure  support Tim Chen <tim.c.chen@linux.intel.com> - 2015-11-18 17:00 +0100
            Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure  support Herbert Xu <herbert@gondor.apana.org.au> - 2015-11-19 01:20 +0100
              Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure  support Tim Chen <tim.c.chen@linux.intel.com> - 2015-11-19 03:40 +0100
                Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure  support Herbert Xu <herbert@gondor.apana.org.au> - 2015-11-19 10:50 +0100

csiph-web