On 02/24/2017 11:32 AM, Harald Freudenberger wrote:
> On 02/24/2017 09:42 AM, Harald Freudenberger wrote:
...
>> ...
>> Feb 24 09:28:10 r35lp49 kernel: 
>> ->crypto_larval_lookup(name=aes,type=0x00000405,mask=0x0000248c)
>> Feb 24 09:28:10 r35lp49 kernel:   crypto_larval_lookup calling 
>> crypto_alg_lookup(aes,0x00000405,0x0000248c)
>> Feb 24 09:28:10 r35lp49 kernel: ->__crypto_alg_lookup(name=aes)
>> Feb 24 09:28:10 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=         
>>  (null)
>> Feb 24 09:28:10 r35lp49 kernel:   crypto_larval_lookup calling 
>> request_module(crypto-aes)
>> Feb 24 09:28:10 r35lp49 kernel:   crypto_larval_lookup calling 
>> request_module(crypto-aes-all)
>>
>> type=0x00000405 = CRYPTO_ALG_TESTED, CRYPTO_ALG_TYPE_SKCIPHER
>> mask=0x0000248c = CRYPTO_ALG_INTERNAL, CRYPTO_ALG_TESTED, CRYPTO_ALG_ASYNC, 
>> CRYPTO_ALG_TYPE_BLKCIPHER_MASK
>>
> I catched it: Thanks Herbert for your hint. The aes algorith registers with:
>   .cra_flags = CRYPTO_ALG_TYPE_CIPHER |CRYPTO_ALG_NEED_FALLBACK
> so later at __crypto_alg_lookup(aes, 0x0405, 0x248c)
> this alg is not choosen because the check
>   if ((q->cra_flags ^ type) & mask)
> is true q->cra_flags = 0x0501 ^ 0x0405 & 0x248x => 0x0004
>
> @Martin, I'll commit a patch asap.
>
> Thanks for your help :-)
>
> regards, H.Freudenberger
>
rollback. Changing the cra_flag CRYPTO_ALG_TYPE_SKCIPHER in the crypto_alg
registration struct is not the right way.
continuing evaluation ...

Reply via email to