RE:

2017-02-23 Thread Qin's Yanjun 

How are you today and your family? I require your attention and honest
co-operation about some issues which i will really want to discuss with you
which.  Looking forward to read from you soon.  

Qin's


__

Sky Silk, http://aknet.kz

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-02-23 Thread Joe Perches 
On Thu, 2017-02-23 at 17:41 +, Emil Velikov wrote:
> On 23 February 2017 at 17:18, Joe Perches  wrote:
> > On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
> > > On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches  wrote:
> > > > There are ~4300 uses of pr_warn and ~250 uses of the older
> > > > pr_warning in the kernel source tree.
> > > > 
> > > > Make the use of pr_warn consistent across all kernel files.
> > > > 
> > > > This excludes all files in tools/ as there is a separate
> > > > define pr_warning for that directory tree and pr_warn is
> > > > not used in tools/.
> > > > 
> > > > Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
> > 
> > []
> > > Where's the removal of pr_warning so we don't have more sneak in?
> > 
> > After all of these actually get applied,
> > and maybe a cycle or two later, one would
> > get sent.
> > 
> 
> By which point you'll get a few reincarnation of it. So you'll have to
> do the same exercise again :-(

Maybe to one or two files.  Not a big deal.

> I guess the question is - are you expecting to get the series merged
> all together/via one tree ?

No.  The only person that could do that effectively is Linus.

> If not, your plan is perfectly reasonable.

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-02-23 Thread Emil Velikov 
On 23 February 2017 at 17:18, Joe Perches  wrote:
> On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
>> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches  wrote:
>> > There are ~4300 uses of pr_warn and ~250 uses of the older
>> > pr_warning in the kernel source tree.
>> >
>> > Make the use of pr_warn consistent across all kernel files.
>> >
>> > This excludes all files in tools/ as there is a separate
>> > define pr_warning for that directory tree and pr_warn is
>> > not used in tools/.
>> >
>> > Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
> []
>> Where's the removal of pr_warning so we don't have more sneak in?
>
> After all of these actually get applied,
> and maybe a cycle or two later, one would
> get sent.
>
By which point you'll get a few reincarnation of it. So you'll have to
do the same exercise again :-(

I guess the question is - are you expecting to get the series merged
all together/via one tree ? If not, your plan is perfectly reasonable.
Fwiw in the DRM subsystem, similar cleanups does purge the respective
macros/other with the final commit. But there one can pull the lot in
one go.

Regards,
Emil

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-02-23 Thread Joe Perches 
On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches  wrote:
> > There are ~4300 uses of pr_warn and ~250 uses of the older
> > pr_warning in the kernel source tree.
> > 
> > Make the use of pr_warn consistent across all kernel files.
> > 
> > This excludes all files in tools/ as there is a separate
> > define pr_warning for that directory tree and pr_warn is
> > not used in tools/.
> > 
> > Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
[]
> Where's the removal of pr_warning so we don't have more sneak in?

After all of these actually get applied,
and maybe a cycle or two later, one would
get sent.

Re: crypto: hang in crypto_larval_lookup

2017-02-23 Thread Harald Freudenberger 
On 02/23/2017 12:39 PM, Herbert Xu wrote:
> On Thu, Feb 23, 2017 at 07:19:57PM +0800, Herbert Xu wrote:
>> Harald Freudenberger  wrote:
>>> Hello all
>>>
>>> I am currently following a hang at modprobe aes_s390 where
>>> crypto_register_alg() does not come back for the xts(aes) algorithm.
>>>
>>> The registration is waiting forever in algapi.c crypto_wait_for_test() but
>>> the completion never occurs. The cryptomgr is triggering a test via
>>> kthread_run to invoce cryptomgr_probe and this thread is calling the
>>> create() function of the xts template (file xts.c). Following this thread
>>> it comes down to api.c crypto_larval_lookup(name="aes") which is first
>>> requesting the module "crypto-aes" via request_module() successful and then
>>> blocking forever in requesting the module "crypto-aes-all".
>>>
>>> The xts(aes) has at registration CRYPTO_ALG_NEED_FALLBACK flag on.
>>>
>>> This problem is seen since about 6 weeks now, first only on the linux next
>>> kernel. Now it appers on the 4.10-rc kernels as well. And I still have no
>>> idea on how this could be fixed or what's wrong with just the xts
>>> registration (ecb, cbc, ctr work fine).
>>>
>>> Any ideas or hints?
>> Sorry, my fault.  I should've converted all the fallback users of
>> the old blkcipher interface over to skcipher before converting the
>> core algorithms to skcipher.
>>
>> I'll send a patch.
> Hmm, actually looks like I did convert this one :)
>
> Do you have ECB enabled in your configuration? XTS doesn't work
> without it.  Currently the Kconfig is missing a select on ECB so
> it could stop the generic XTS from loading.
>
> However, you seem to be stuck on straight AES which quite strange.
> The reason is that s390 crypto registers AES as the first thing so
> it should already be available.
>
> The fact that it hangs is expected because it's trying to find
> an acceptable AES implementation and in doing so it's loading
> s390-aes again.
>
> So we need to get to the bottom of why there is no acceptable
> "aes" registered.  Can you check /proc/crypto to see if the simple
> aes cipher is correctly registered (passing the selftest) after
> it hangs?
>
> You could also print out the type/mask in crypto_larval_lookup
> to see if perhaps the caller is asking for something unreasonable.
>
> Thanks,
Thanks for your help, here is cat /proc/crypto:
name : xts(aes)
driver   :
module   : kernel
priority : -1
refcnt   : 3
selftest : passed
internal : no
type : larval
flags: 0x415

name : xts(aes)
driver   : xts-aes-s390
module   : kernel
priority : 400
refcnt   : 1
selftest : passed
internal : no
type : larval
flags: 0x514

name : xts(aes)
driver   : xts-aes-s390
module   : aes_s390
priority : 400
refcnt   : 4
selftest : unknown
internal : no
type : blkcipher
blocksize: 16
min keysize  : 32
max keysize  : 64
ivsize   : 16
geniv: 

...

name : ecb(aes)
driver   : ecb(aes-s390)
module   : kernel
priority : 300
refcnt   : 1
selftest : passed
internal : no
type : blkcipher
blocksize: 16
min keysize  : 16
max keysize  : 32
ivsize   : 0
geniv: 

name : ecb(aes)
driver   : ecb-aes-s390
module   : aes_s390
priority : 400
refcnt   : 1
selftest : passed
internal : no
type : blkcipher
blocksize: 16
min keysize  : 16
max keysize  : 32
ivsize   : 0
geniv: 

name : aes
driver   : aes-s390
module   : aes_s390
priority : 300
refcnt   : 1
selftest : passed
internal : no
type : cipher
blocksize: 16
min keysize  : 16
max keysize  : 32
...

at the time where the modprobe hangs.

And here is some syslog output (I added some printks for debugging) maybe
it may give you some hints about whats going on during the modprobe:
Feb 23 16:52:08 r35lp49 kernel:   crypto_larval_lookup calling 
crypto_alg_lookup()
Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
Feb 23 16:52:08 r35lp49 kernel:   crypto_alg_get(alg.cra_name=aes) 
alg=00f2dd68 alg.cra_refcnt=2
Feb 23 16:52:08 r35lp49 kernel:   crypto_mod_get(alg.cra_name=aes 
alg=00f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) 
alg=00f2dd68
Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) 
alg=00f2dd68
Feb 23 16:52:08 r35lp49 kernel:   crypto_mod_put(alg.cra_name=aes 
alg=00f2dd68 alg.cra_driver_name=aes-generic, 
alg.cra_module.name=(null))
Feb 23 16:52:08 r35lp49 kernel:   crypto_alg_put(alg.cra_name=aes 
alg=00f2dd68 alg.cra_refcnt=2)
Feb 23 16:52:08 r35lp49 kernel:   crypto_mod_put(alg.cra_name=aes 
alg=03ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390)
Feb 23 16:52:08 r35lp49 kernel:

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-02-23 Thread Rob Herring 
On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches  wrote:
> There are ~4300 uses of pr_warn and ~250 uses of the older
> pr_warning in the kernel source tree.
>
> Make the use of pr_warn consistent across all kernel files.
>
> This excludes all files in tools/ as there is a separate
> define pr_warning for that directory tree and pr_warn is
> not used in tools/.
>
> Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
>
> Some files not compiled - no cross-compilers
>
> Joe Perches (35):
>   alpha: Convert remaining uses of pr_warning to pr_warn
>   ARM: ep93xx: Convert remaining uses of pr_warning to pr_warn
>   arm64: Convert remaining uses of pr_warning to pr_warn
>   arch/blackfin: Convert remaining uses of pr_warning to pr_warn
>   ia64: Convert remaining use of pr_warning to pr_warn
>   powerpc: Convert remaining uses of pr_warning to pr_warn
>   sh: Convert remaining uses of pr_warning to pr_warn
>   sparc: Convert remaining use of pr_warning to pr_warn
>   x86: Convert remaining uses of pr_warning to pr_warn
>   drivers/acpi: Convert remaining uses of pr_warning to pr_warn
>   block/drbd: Convert remaining uses of pr_warning to pr_warn
>   gdrom: Convert remaining uses of pr_warning to pr_warn
>   drivers/char: Convert remaining use of pr_warning to pr_warn
>   clocksource: Convert remaining use of pr_warning to pr_warn
>   drivers/crypto: Convert remaining uses of pr_warning to pr_warn
>   fmc: Convert remaining use of pr_warning to pr_warn
>   drivers/gpu: Convert remaining uses of pr_warning to pr_warn
>   drivers/ide: Convert remaining uses of pr_warning to pr_warn
>   drivers/input: Convert remaining uses of pr_warning to pr_warn
>   drivers/isdn: Convert remaining uses of pr_warning to pr_warn
>   drivers/macintosh: Convert remaining uses of pr_warning to pr_warn
>   drivers/media: Convert remaining use of pr_warning to pr_warn
>   drivers/mfd: Convert remaining uses of pr_warning to pr_warn
>   drivers/mtd: Convert remaining uses of pr_warning to pr_warn
>   drivers/of: Convert remaining uses of pr_warning to pr_warn
>   drivers/oprofile: Convert remaining uses of pr_warning to pr_warn
>   drivers/platform: Convert remaining uses of pr_warning to pr_warn
>   drivers/rapidio: Convert remaining use of pr_warning to pr_warn
>   drivers/scsi: Convert remaining use of pr_warning to pr_warn
>   drivers/sh: Convert remaining use of pr_warning to pr_warn
>   drivers/tty: Convert remaining uses of pr_warning to pr_warn
>   drivers/video: Convert remaining uses of pr_warning to pr_warn
>   kernel/trace: Convert remaining uses of pr_warning to pr_warn
>   lib: Convert remaining uses of pr_warning to pr_warn
>   sound/soc: Convert remaining uses of pr_warning to pr_warn

Where's the removal of pr_warning so we don't have more sneak in?

Rob

Re: [PATCH 1/2] crypto: vmx - Use skcipher for cbc fallback

2017-02-23 Thread Marcelo Cerri 
It makes sense. Thanks for the clarification, Herbert.

One more question: are you planning to convert the ctr template to
skcipher?

-- 
Regards,
Marcelo

On Thu, Feb 23, 2017 at 07:21:56PM +0800, Herbert Xu wrote:
> Marcelo Cerri  wrote:
> >
> > I noticed you used a similar approach in arch/s390/crypto/aes_s390.c
> > (commit 64e2680).
> > 
> > How do you ensure the skcipher operation will not be asynchronous? 
> 
> You need to set the bit CRYPTO_ALG_ASYNC in the mask field when
> allocating the algorithm to ensure that it's synchronous.
> 
> Cheers,
> -- 
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt



signature.asc
Description: PGP signature

Crypto Update for 4.11

2017-02-23 Thread Herbert Xu 
Hi Linus: 

Here is the crypto update for 4.11:

API:

- Try to catch hash output overrun in testmgr.
- Introduce walksize attribute for batched walking.
- Make crypto_xor() and crypto_inc() alignment agnostic.

Algorithms:

- Add time-invariant AES algorithm.
- Add standalone CBCMAC algorithm.

Drivers:

- Add NEON acclerated chacha20 on ARM/ARM64.
- Expose AES-CTR as synchronous skcipher on ARM64.
- Add scalar AES implementation on ARM64.
- Improve scalar AES implementation on ARM.
- Improve NEON AES implementation on ARM/ARM64.
- Merge CRC32 and PMULL instruction based drivers on ARM64.
- Add NEON acclerated CBCMAC/CMAC/XCBC AES on ARM64.
- Add IPsec AUTHENC implementation in atmel.
- Add Support for Octeon-tx CPT Engine.
- Add Broadcom SPU driver.
- Add MediaTek driver.


Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus


Ahsan Atta (2):
  crypto: qat - fix indentation
  crypto: qat - fix comments describing adf_disable_sriov()

Andrew Lutomirski (1):
  crypto: testmgr - Allocate only the required output size for hash tests

Ard Biesheuvel (33):
  crypto: arm64/chacha20 - implement NEON version based on SSE3 code
  crypto: arm/chacha20 - implement NEON version based on SSE3 code
  crypto: chacha20 - convert generic and x86 versions to skcipher
  crypto: skcipher - introduce walksize attribute for SIMD algos
  crypto: arm64/aes-blk - expose AES-CTR as synchronous cipher as well
  crypto: arm64/aes - add scalar implementation
  crypto: arm/aes - replace scalar AES cipher
  crypto: arm64/aes - reimplement bit-sliced ARM/NEON implementation for 
arm64
  crypto: arm/aes - replace bit-sliced OpenSSL NEON code
  crypto: testmgr - use calculated count for number of test vectors
  crypto: arm/aes - avoid reserved 'tt' mnemonic in asm code
  crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes
  crypto: arm/aes-neonbs - fix issue with v2.22 and older assembler
  crypto: arm/aes-ce - remove cra_alignmask
  crypto: arm/chacha20 - remove cra_alignmask
  crypto: arm64/aes-ce-ccm - remove cra_alignmask
  crypto: arm64/aes-blk - remove cra_alignmask
  crypto: arm64/chacha20 - remove cra_alignmask
  crypto: arm64/aes - avoid literals for cross-module symbol references
  crypto: arm64/aes - performance tweak
  crypto: arm64/aes-neon-blk - tweak performance for low end cores
  crypto: arm64/aes - replace scalar fallback with plain NEON fallback
  crypto: arm64/aes - don't use IV buffer to return final keystream block
  crypto: arm/aes - don't use IV buffer to return final keystream block
  crypto: arm64/crc32 - merge CRC32 and PMULL instruction based drivers
  crypto: aes-generic - drop alignment requirement
  crypto: aes - add generic time invariant AES cipher
  crypto: testmgr - add test cases for cbcmac(aes)
  crypto: ccm - switch to separate cbcmac driver
  crypto: arm64/aes - add NEON/Crypto Extensions CBCMAC/CMAC/XCBC driver
  crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic
  crypto: ccm - honour alignmask of subordinate MAC cipher
  crypto: ccm - drop unnecessary minimum 32-bit alignment

Arnd Bergmann (6):
  crypto: mediatek - remove ARM dependencies
  crypto: mediatek - fix format string for 64-bit builds
  crypto: improve gcc optimization flags for serpent and wp512
  crypto: atmel - refine Kconfig dependencies
  crypto: atmel - fix 64-bit build warnings
  crypto: cavium - fix Kconfig dependencies

Christoph Hellwig (3):
  crypto: cavium - remove dead MSI-X related define
  crypto: cavium - switch to pci_alloc_irq_vectors
  crypto: cavium - switch to pci_alloc_irq_vectors

Colin Ian King (1):
  crypto: mediatek - don't return garbage err on successful return

Corentin LABBE (9):
  crypto: drivers - bring back alphabetical order of Makefile
  hwrng: core - do not use multiple blank lines
  hwrng: core - rewrite better comparison to NULL
  hwrng: core - Rewrite the header
  hwrng: core - Replace asm/uaccess.h by linux/uaccess.h
  hwrng: core - Move hwrng miscdev minor number to 
include/linux/miscdevice.h
  hwrng: core - remove unused PFX macro
  crypto: bfin_crc - Fix format printing warning
  crypto: bfin_crc - Remove unneeded linux/miscdevice.h include

Cyrille Pitchen (14):
  crypto: atmel-sha - create function to get an Atmel SHA device
  crypto: atmel-sha - update request queue management to make it more 
generic
  crypto: atmel-sha - make atmel_sha_done_task more generic
  crypto: atmel-sha - redefine SHA_FLAGS_SHA* flags to match 
SHA_MR_ALGO_SHA*
  crypto: atmel-sha - add atmel_sha_wait_for_data_ready()
  crypto: atmel-sha - add SHA_MR_MODE_IDATAR0
  crypto: atmel-sha - add atmel_sha_cpu_start()
  crypto: atmel-sha - add simple DMA transfers
  crypto: atmel-sha - add

Re: [PATCH] crypto: Add ECB dependency for XTS mode

2017-02-23 Thread Herbert Xu 
On Thu, Feb 23, 2017 at 08:38:26AM +0100, Milan Broz wrote:
> Since the
>commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
>crypto: xts - Convert to skcipher
> the XTS mode is based on ECB, so the mode must select
> ECB otherwise it can fail to initialize.
> 
> Signed-off-by: Milan Broz 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: crypto/cavium MSI-X fixups

2017-02-23 Thread Herbert Xu 
On Wed, Feb 15, 2017 at 08:18:40AM +0100, Christoph Hellwig wrote:
> Hi George,
> 
> your commit "crypto: cavium - Add Support for Octeon-tx CPT Engine"
> add a new caller to pci_enable_msix.  This API has long been deprecated
> so this series switches it to use pci_alloc_irq_vectors instead.
> 
> Can you please test it and make sure it goes in before the end of the
> merge window so that no more users of the old API hit mainline?

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: crypto: hang in crypto_larval_lookup

2017-02-23 Thread Herbert Xu 
Harald Freudenberger  wrote:
> 
> Hello all
> 
> I am currently following a hang at modprobe aes_s390 where
> crypto_register_alg() does not come back for the xts(aes) algorithm.
> 
> The registration is waiting forever in algapi.c crypto_wait_for_test() but
> the completion never occurs. The cryptomgr is triggering a test via
> kthread_run to invoce cryptomgr_probe and this thread is calling the
> create() function of the xts template (file xts.c). Following this thread
> it comes down to api.c crypto_larval_lookup(name="aes") which is first
> requesting the module "crypto-aes" via request_module() successful and then
> blocking forever in requesting the module "crypto-aes-all".
> 
> The xts(aes) has at registration CRYPTO_ALG_NEED_FALLBACK flag on.
> 
> This problem is seen since about 6 weeks now, first only on the linux next
> kernel. Now it appers on the 4.10-rc kernels as well. And I still have no
> idea on how this could be fixed or what's wrong with just the xts
> registration (ecb, cbc, ctr work fine).
> 
> Any ideas or hints?

Sorry, my fault.  I should've converted all the fallback users of
the old blkcipher interface over to skcipher before converting the
core algorithms to skcipher.

I'll send a patch.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: crypto: hang in crypto_larval_lookup

2017-02-23 Thread Herbert Xu 
On Thu, Feb 23, 2017 at 07:19:57PM +0800, Herbert Xu wrote:
> Harald Freudenberger  wrote:
> > 
> > Hello all
> > 
> > I am currently following a hang at modprobe aes_s390 where
> > crypto_register_alg() does not come back for the xts(aes) algorithm.
> > 
> > The registration is waiting forever in algapi.c crypto_wait_for_test() but
> > the completion never occurs. The cryptomgr is triggering a test via
> > kthread_run to invoce cryptomgr_probe and this thread is calling the
> > create() function of the xts template (file xts.c). Following this thread
> > it comes down to api.c crypto_larval_lookup(name="aes") which is first
> > requesting the module "crypto-aes" via request_module() successful and then
> > blocking forever in requesting the module "crypto-aes-all".
> > 
> > The xts(aes) has at registration CRYPTO_ALG_NEED_FALLBACK flag on.
> > 
> > This problem is seen since about 6 weeks now, first only on the linux next
> > kernel. Now it appers on the 4.10-rc kernels as well. And I still have no
> > idea on how this could be fixed or what's wrong with just the xts
> > registration (ecb, cbc, ctr work fine).
> > 
> > Any ideas or hints?
> 
> Sorry, my fault.  I should've converted all the fallback users of
> the old blkcipher interface over to skcipher before converting the
> core algorithms to skcipher.
> 
> I'll send a patch.

Hmm, actually looks like I did convert this one :)

Do you have ECB enabled in your configuration? XTS doesn't work
without it.  Currently the Kconfig is missing a select on ECB so
it could stop the generic XTS from loading.

However, you seem to be stuck on straight AES which quite strange.
The reason is that s390 crypto registers AES as the first thing so
it should already be available.

The fact that it hangs is expected because it's trying to find
an acceptable AES implementation and in doing so it's loading
s390-aes again.

So we need to get to the bottom of why there is no acceptable
"aes" registered.  Can you check /proc/crypto to see if the simple
aes cipher is correctly registered (passing the selftest) after
it hangs?

You could also print out the type/mask in crypto_larval_lookup
to see if perhaps the caller is asking for something unreasonable.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 1/2] crypto: vmx - Use skcipher for cbc fallback

2017-02-23 Thread Herbert Xu 
Paulo Flabiano Smorigo  wrote:
>
>fallback =
> -   crypto_alloc_blkcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
> +   crypto_alloc_skcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);

You need to add CRYPTO_ALG_ASYNC to the mask in order to ensure
that you get a sync algorithm.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 1/2] crypto: vmx - Use skcipher for cbc fallback

2017-02-23 Thread Herbert Xu 
Marcelo Cerri  wrote:
>
> I noticed you used a similar approach in arch/s390/crypto/aes_s390.c
> (commit 64e2680).
> 
> How do you ensure the skcipher operation will not be asynchronous? 

You need to set the bit CRYPTO_ALG_ASYNC in the mask field when
allocating the algorithm to ensure that it's synchronous.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt