* crypto: hang in crypto_larval_lookup @ 2017-02-17 17:50 Harald Freudenberger 2017-02-23 11:19 ` Herbert Xu 0 siblings, 1 reply; 13+ messages in thread From: Harald Freudenberger @ 2017-02-17 17:50 UTC (permalink / raw) To: linux-crypto; +Cc: herbert, Martin Schwidefsky 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? Thank's in advance. regards Harald Freudenberger ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup 2017-02-17 17:50 crypto: hang in crypto_larval_lookup Harald Freudenberger @ 2017-02-23 11:19 ` Herbert Xu 2017-02-23 11:39 ` Herbert Xu 0 siblings, 1 reply; 13+ messages in thread From: Herbert Xu @ 2017-02-23 11:19 UTC (permalink / raw) To: Harald Freudenberger; +Cc: linux-crypto, schwidefsky Harald Freudenberger <freude@linux.vnet.ibm.com> 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 <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup 2017-02-23 11:19 ` Herbert Xu @ 2017-02-23 11:39 ` Herbert Xu 2017-02-23 16:02 ` Harald Freudenberger 2017-02-24 23:44 ` Marcelo Cerri 0 siblings, 2 replies; 13+ messages in thread From: Herbert Xu @ 2017-02-23 11:39 UTC (permalink / raw) To: Harald Freudenberger; +Cc: linux-crypto, schwidefsky On Thu, Feb 23, 2017 at 07:19:57PM +0800, Herbert Xu wrote: > Harald Freudenberger <freude@linux.vnet.ibm.com> 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 <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup 2017-02-23 11:39 ` Herbert Xu @ 2017-02-23 16:02 ` Harald Freudenberger 2017-02-24 8:42 ` Harald Freudenberger 2017-02-24 23:44 ` Marcelo Cerri 1 sibling, 1 reply; 13+ messages in thread From: Harald Freudenberger @ 2017-02-23 16:02 UTC (permalink / raw) To: Herbert Xu; +Cc: linux-crypto, schwidefsky 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 <freude@linux.vnet.ibm.com> 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 : <default> ... 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 : <default> 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 : <default> 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=0000000000f2dd68 alg.cra_refcnt=2 Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null)) Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=0000000000f2dd68 Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) alg=0000000000f2dd68 Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=0000000000f2dd68 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=0000000000f2dd68 alg.cra_refcnt=2) Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_refcnt=2) Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=4) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=cbc(aes)) alg=00000000b92d3548 alg.cra_refcnt=4 Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390) alg.cra_module.name=(null)) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d4598 alg.cra_refcnt=1) Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=4) Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=3) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=3) Feb 23 16:52:08 r35lp49 kernel: <-cryptomgr_probe(data=00000000b8b5d698) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=cbc(aes)) alg=00000000b92d3548 alg.cra_refcnt=3 Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390) alg.cra_module.name=(null)) Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_driver_name=, alg.cra_module.name=(null)) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=2) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=1) Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=3) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=aes) alg=000003ff80178480 alg.cra_refcnt=2 Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390 alg.cra_module.name=aes_s390) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=aes) Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=aes) 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=0000000000f2dd68 alg.cra_refcnt=2 Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null)) Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=0000000000f2dd68 Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) alg=0000000000f2dd68 Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=0000000000f2dd68 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=0000000000f2dd68 alg.cra_refcnt=2) Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_refcnt=2) Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=2) Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=4) Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=3) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d4248 alg.cra_refcnt=1) Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=2) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=2 Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390) Feb 23 16:52:08 r35lp49 kernel: cryptomgr_notify(data=000003ff80178120) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=xts-aes-s390) Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=xts-aes-s390) 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=xts-aes-s390) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=3 Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390) Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts-aes-s390) alg=000003ff80178120 Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=xts-aes-s390) alg=000003ff80178120 Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=4 Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=xts(aes)) Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=xts(aes)) 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=xts(aes)) Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null) Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-xts(aes)) Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup(xts(aes)) Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes)) Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null) Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_larval_add(xts(aes)) Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes)) Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null) Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=xts(aes)) alg=00000000b92d48e8 Feb 23 16:52:08 r35lp49 kernel: cryptomgr_notify(data=00000000b92d48e8) Feb 23 16:52:08 r35lp49 kernel: cryptomgr_schedule_probe(larval=00000000b92d48e8 larval.alg=00000000b92d48e8) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=00000000b92d48e8 alg.cra_refcnt=3 Feb 23 16:52:08 r35lp49 kernel: ->cryptomgr_probe(data=00000000b8b5d698 param.larval=00000000b92d48e8 param.larval.alg=00000000b92d48e8) Feb 23 16:52:08 r35lp49 kernel: ->__crypto_lookup_template(xts) Feb 23 16:52:08 r35lp49 kernel: <-__crypto_lookup_template() tmpl=0000000000f2dc00 Feb 23 16:52:08 r35lp49 kernel: cryptomgr_probe(data=00000000b8b5d698) tmpl=0000000000f2dc00 tmpl.create=00000000006e00b8 err=-11 Feb 23 16:52:08 r35lp49 kernel: ->create(tmpl.name=xts) Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=aes) Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=aes) 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_lookup(name=aes) alg= (null) Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes) Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes-all) --- modprobe aes_s390 hang --- regards H.Freudenberger ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup 2017-02-23 16:02 ` Harald Freudenberger @ 2017-02-24 8:42 ` Harald Freudenberger 2017-02-24 10:32 ` Harald Freudenberger 0 siblings, 1 reply; 13+ messages in thread From: Harald Freudenberger @ 2017-02-24 8:42 UTC (permalink / raw) To: Herbert Xu; +Cc: linux-crypto, schwidefsky On 02/23/2017 05:02 PM, Harald Freudenberger wrote: > 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 <freude@linux.vnet.ibm.com> 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 : <default> > > ... > > 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 : <default> > > 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 : <default> > > 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=0000000000f2dd68 alg.cra_refcnt=2 > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null)) > Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=0000000000f2dd68 > Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) alg=0000000000f2dd68 > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=0000000000f2dd68 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=0000000000f2dd68 alg.cra_refcnt=2) > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_refcnt=2) > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=4) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=cbc(aes)) alg=00000000b92d3548 alg.cra_refcnt=4 > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390) alg.cra_module.name=(null)) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d4598 alg.cra_refcnt=1) > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=4) > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=3) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=3) > Feb 23 16:52:08 r35lp49 kernel: <-cryptomgr_probe(data=00000000b8b5d698) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=cbc(aes)) alg=00000000b92d3548 alg.cra_refcnt=3 > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390) alg.cra_module.name=(null)) > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_driver_name=, alg.cra_module.name=(null)) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=2) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=1) > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=3) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=aes) alg=000003ff80178480 alg.cra_refcnt=2 > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390 alg.cra_module.name=aes_s390) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=aes) > Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=aes) > 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=0000000000f2dd68 alg.cra_refcnt=2 > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null)) > Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=0000000000f2dd68 > Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) alg=0000000000f2dd68 > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=0000000000f2dd68 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=0000000000f2dd68 alg.cra_refcnt=2) > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_refcnt=2) > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=2) > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=4) > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=3) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d4248 alg.cra_refcnt=1) > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=2) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=2 > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390) > Feb 23 16:52:08 r35lp49 kernel: cryptomgr_notify(data=000003ff80178120) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=xts-aes-s390) > Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=xts-aes-s390) > 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=xts-aes-s390) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=3 > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390) > Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts-aes-s390) alg=000003ff80178120 > Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=xts-aes-s390) alg=000003ff80178120 > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=4 > Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=xts(aes)) > Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=xts(aes)) > 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=xts(aes)) > Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null) > Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-xts(aes)) > Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup(xts(aes)) > Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes)) > Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null) > Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_larval_add(xts(aes)) > Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes)) > Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null) > Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=xts(aes)) alg=00000000b92d48e8 > Feb 23 16:52:08 r35lp49 kernel: cryptomgr_notify(data=00000000b92d48e8) > Feb 23 16:52:08 r35lp49 kernel: cryptomgr_schedule_probe(larval=00000000b92d48e8 larval.alg=00000000b92d48e8) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=00000000b92d48e8 alg.cra_refcnt=3 > Feb 23 16:52:08 r35lp49 kernel: ->cryptomgr_probe(data=00000000b8b5d698 param.larval=00000000b92d48e8 param.larval.alg=00000000b92d48e8) > Feb 23 16:52:08 r35lp49 kernel: ->__crypto_lookup_template(xts) > Feb 23 16:52:08 r35lp49 kernel: <-__crypto_lookup_template() tmpl=0000000000f2dc00 > Feb 23 16:52:08 r35lp49 kernel: cryptomgr_probe(data=00000000b8b5d698) tmpl=0000000000f2dc00 tmpl.create=00000000006e00b8 err=-11 > Feb 23 16:52:08 r35lp49 kernel: ->create(tmpl.name=xts) > Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=aes) > Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=aes) > 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_lookup(name=aes) alg= (null) > Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes) > Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes-all) > --- modprobe aes_s390 hang --- > > regards H.Freudenberger > Here are the type and mask values: ... 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup 2017-02-24 8:42 ` Harald Freudenberger @ 2017-02-24 10:32 ` Harald Freudenberger 2017-02-24 11:21 ` Harald Freudenberger 0 siblings, 1 reply; 13+ messages in thread From: Harald Freudenberger @ 2017-02-24 10:32 UTC (permalink / raw) To: Herbert Xu; +Cc: linux-crypto, schwidefsky On 02/24/2017 09:42 AM, Harald Freudenberger wrote: > On 02/23/2017 05:02 PM, Harald Freudenberger wrote: >> 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 <freude@linux.vnet.ibm.com> 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 : <default> >> >> ... >> >> 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 : <default> >> >> 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 : <default> >> >> 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=0000000000f2dd68 alg.cra_refcnt=2 >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null)) >> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=0000000000f2dd68 >> Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) alg=0000000000f2dd68 >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=0000000000f2dd68 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=0000000000f2dd68 alg.cra_refcnt=2) >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_refcnt=2) >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=4) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=cbc(aes)) alg=00000000b92d3548 alg.cra_refcnt=4 >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390) alg.cra_module.name=(null)) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d4598 alg.cra_refcnt=1) >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=4) >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=3) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=3) >> Feb 23 16:52:08 r35lp49 kernel: <-cryptomgr_probe(data=00000000b8b5d698) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=cbc(aes)) alg=00000000b92d3548 alg.cra_refcnt=3 >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390) alg.cra_module.name=(null)) >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_driver_name=, alg.cra_module.name=(null)) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=2) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3858 alg.cra_refcnt=1) >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=3) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=aes) alg=000003ff80178480 alg.cra_refcnt=2 >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390 alg.cra_module.name=aes_s390) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=aes) >> Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=aes) >> 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=0000000000f2dd68 alg.cra_refcnt=2 >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=aes alg=0000000000f2dd68 alg.cra_driver_name=aes-generic alg.cra_module.name=(null)) >> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=aes) alg=0000000000f2dd68 >> Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=aes) alg=0000000000f2dd68 >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=0000000000f2dd68 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=0000000000f2dd68 alg.cra_refcnt=2) >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_driver_name=aes-s390, alg.cra_module.name=aes_s390) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=aes alg=000003ff80178480 alg.cra_refcnt=2) >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_driver_name=cbc(aes-s390), alg.cra_module.name=(null)) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d3548 alg.cra_refcnt=2) >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=4) >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=3) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=00000000b92d4248 alg.cra_refcnt=1) >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_driver_name=cbc-aes-s390, alg.cra_module.name=aes_s390) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_put(alg.cra_name=cbc(aes) alg=000003ff80178240 alg.cra_refcnt=2) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=2 >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390) >> Feb 23 16:52:08 r35lp49 kernel: cryptomgr_notify(data=000003ff80178120) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=xts-aes-s390) >> Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=xts-aes-s390) >> 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=xts-aes-s390) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=3 >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390) >> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts-aes-s390) alg=000003ff80178120 >> Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=xts-aes-s390) alg=000003ff80178120 >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=000003ff80178120 alg.cra_refcnt=4 >> Feb 23 16:52:08 r35lp49 kernel: crypto_mod_get(alg.cra_name=xts(aes) alg=000003ff80178120 alg.cra_driver_name=xts-aes-s390 alg.cra_module.name=aes_s390) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=xts(aes)) >> Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=xts(aes)) >> 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=xts(aes)) >> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null) >> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-xts(aes)) >> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_alg_lookup(xts(aes)) >> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes)) >> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null) >> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling crypto_larval_add(xts(aes)) >> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_alg_lookup(name=xts(aes)) >> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_alg_lookup(name=xts(aes)) alg= (null) >> Feb 23 16:52:08 r35lp49 kernel: <-crypto_larval_lookup(name=xts(aes)) alg=00000000b92d48e8 >> Feb 23 16:52:08 r35lp49 kernel: cryptomgr_notify(data=00000000b92d48e8) >> Feb 23 16:52:08 r35lp49 kernel: cryptomgr_schedule_probe(larval=00000000b92d48e8 larval.alg=00000000b92d48e8) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_get(alg.cra_name=xts(aes)) alg=00000000b92d48e8 alg.cra_refcnt=3 >> Feb 23 16:52:08 r35lp49 kernel: ->cryptomgr_probe(data=00000000b8b5d698 param.larval=00000000b92d48e8 param.larval.alg=00000000b92d48e8) >> Feb 23 16:52:08 r35lp49 kernel: ->__crypto_lookup_template(xts) >> Feb 23 16:52:08 r35lp49 kernel: <-__crypto_lookup_template() tmpl=0000000000f2dc00 >> Feb 23 16:52:08 r35lp49 kernel: cryptomgr_probe(data=00000000b8b5d698) tmpl=0000000000f2dc00 tmpl.create=00000000006e00b8 err=-11 >> Feb 23 16:52:08 r35lp49 kernel: ->create(tmpl.name=xts) >> Feb 23 16:52:08 r35lp49 kernel: crypto_alg_mod_lookup(name=aes) >> Feb 23 16:52:08 r35lp49 kernel: ->crypto_larval_lookup(name=aes) >> 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_lookup(name=aes) alg= (null) >> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes) >> Feb 23 16:52:08 r35lp49 kernel: crypto_larval_lookup calling request_module(crypto-aes-all) >> --- modprobe aes_s390 hang --- >> >> regards H.Freudenberger >> > Here are the type and mask values: > > ... > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup 2017-02-24 10:32 ` Harald Freudenberger @ 2017-02-24 11:21 ` Harald Freudenberger 0 siblings, 0 replies; 13+ messages in thread From: Harald Freudenberger @ 2017-02-24 11:21 UTC (permalink / raw) To: Herbert Xu; +Cc: linux-crypto, schwidefsky 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 ... ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup 2017-02-23 11:39 ` Herbert Xu 2017-02-23 16:02 ` Harald Freudenberger @ 2017-02-24 23:44 ` Marcelo Cerri 2017-02-25 15:17 ` Herbert Xu 1 sibling, 1 reply; 13+ messages in thread From: Marcelo Cerri @ 2017-02-24 23:44 UTC (permalink / raw) To: Herbert Xu; +Cc: Harald Freudenberger, linux-crypto, schwidefsky [-- Attachment #1: Type: text/plain, Size: 4454 bytes --] On Thu, Feb 23, 2017 at 07:39:09PM +0800, Herbert Xu wrote: > On Thu, Feb 23, 2017 at 07:19:57PM +0800, Herbert Xu wrote: > > Harald Freudenberger <freude@linux.vnet.ibm.com> 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? This is probably caused by the way that the xts template is handling the underline algorithm selection. In the create function in crypto/xts.c: static int create(struct crypto_template *tmpl, struct rtattr **tb) { ... crypto_set_skcipher_spawn(&ctx->spawn, skcipher_crypto_instance(inst)); err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0, crypto_requires_sync(algt->type, algt->mask)); if (err == -ENOENT) { err = -ENAMETOOLONG; if (snprintf(ctx->name, CRYPTO_MAX_ALG_NAME, "ecb(%s)", cipher_name) >= CRYPTO_MAX_ALG_NAME) goto err_free_inst; err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0, crypto_requires_sync(algt->type, algt->mask)); } ... Then when the aes_s390 driver tries to allocate its fallback based on its name ("xts(aes)"), the xts template will first look for an skcipher "aes" algorithm, that doesn't exist. And because of that crypto_larval_lookup will try to load the correspondent alias. Also, since the template does not use the requested flag CRYPTO_ALG_NEED_FALLBACK when it selects the underline algorithm, the -all alias is also requested. A simple workaround is to try the ecb algorithm before the original algorithm. However this still can lead to the same problem when no ecb implementation is available, not even by the driver itself. Another improvement that can be useful is to honor the requested CRYPTO_ALG_NEED_FALLBACK flag when selecting the underline algorithm. It's very likely that the aes_s390 driver will end up using the following chain of fallback algorithms: xts-aes-s390 -> xts(ecb-aes-s390) -> xts(ecb(aes-s390)) -> xts(ecb(aes-generic)) A similar scenario occurs for the vmx-crypto driver. > > 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 <herbert@gondor.apana.org.au> > Home Page: http://gondor.apana.org.au/~herbert/1111 > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Regards, Marcelo [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup 2017-02-24 23:44 ` Marcelo Cerri @ 2017-02-25 15:17 ` Herbert Xu 2017-02-25 19:20 ` Marcelo Cerri 0 siblings, 1 reply; 13+ messages in thread From: Herbert Xu @ 2017-02-25 15:17 UTC (permalink / raw) To: Marcelo Cerri; +Cc: Harald Freudenberger, linux-crypto, schwidefsky On Fri, Feb 24, 2017 at 08:44:00PM -0300, Marcelo Cerri wrote: > > This is probably caused by the way that the xts template is handling the > underline algorithm selection. Good catch. I think the bigger issue here is that when requesting for an XTS that doesn't need a fallback we shouldn't be using an underlying ECB that needs one. So this patch should fix the hang. Thanks, ---8<--- Subject: crypto: xts - Propagate NEED_FALLBACK bit When we're used as a fallback algorithm, we should propagate the NEED_FALLBACK bit when searching for the underlying ECB mode. This just happens to fix a hang too because otherwise the search may end up loading the same module that triggered this XTS creation. Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher") Reported-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> diff --git a/crypto/xts.c b/crypto/xts.c index 410a2e2..2066161 100644 --- a/crypto/xts.c +++ b/crypto/xts.c @@ -463,6 +463,7 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb) struct xts_instance_ctx *ctx; struct skcipher_alg *alg; const char *cipher_name; + u32 mask; int err; algt = crypto_get_attr_type(tb); @@ -483,18 +484,19 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb) ctx = skcipher_instance_ctx(inst); crypto_set_skcipher_spawn(&ctx->spawn, skcipher_crypto_instance(inst)); - err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0, - crypto_requires_sync(algt->type, - algt->mask)); + + mask = crypto_requires_sync(algt->type, algt->mask) | + ((algt->type ^ CRYPTO_ALG_NEED_FALLBACK) & algt->mask & + CRYPTO_ALG_NEED_FALLBACK); + + err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0, mask); if (err == -ENOENT) { err = -ENAMETOOLONG; if (snprintf(ctx->name, CRYPTO_MAX_ALG_NAME, "ecb(%s)", cipher_name) >= CRYPTO_MAX_ALG_NAME) goto err_free_inst; - err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0, - crypto_requires_sync(algt->type, - algt->mask)); + err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0, mask); } if (err) -- 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 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup 2017-02-25 15:17 ` Herbert Xu @ 2017-02-25 19:20 ` Marcelo Cerri 2017-02-26 4:22 ` Herbert Xu 0 siblings, 1 reply; 13+ messages in thread From: Marcelo Cerri @ 2017-02-25 19:20 UTC (permalink / raw) To: Herbert Xu; +Cc: Harald Freudenberger, linux-crypto, schwidefsky [-- Attachment #1: Type: text/plain, Size: 3093 bytes --] On Sat, Feb 25, 2017 at 11:17:07PM +0800, Herbert Xu wrote: > On Fri, Feb 24, 2017 at 08:44:00PM -0300, Marcelo Cerri wrote: > > > > This is probably caused by the way that the xts template is handling the > > underline algorithm selection. > > Good catch. I think the bigger issue here is that when requesting > for an XTS that doesn't need a fallback we shouldn't be using an > underlying ECB that needs one. So this patch should fix the hang. Yeah, I agree. This should work as long as the module aliases are correct, which is enough. Other templates will not trigger the same error since they don't have to try more than one underlying algorithm. But I think this is still desirable for the remaining templates to avoid a long chain of unused fallbacks as in the example I gave in my previous email. Probably a helper function to return the correct mask might be useful for readability and to avoid duplicate code. > > Thanks, > > ---8<--- > Subject: crypto: xts - Propagate NEED_FALLBACK bit > > When we're used as a fallback algorithm, we should propagate > the NEED_FALLBACK bit when searching for the underlying ECB mode. > > This just happens to fix a hang too because otherwise the search > may end up loading the same module that triggered this XTS creation. > > Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher") > Reported-by: Harald Freudenberger <freude@linux.vnet.ibm.com> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> > > diff --git a/crypto/xts.c b/crypto/xts.c > index 410a2e2..2066161 100644 > --- a/crypto/xts.c > +++ b/crypto/xts.c > @@ -463,6 +463,7 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb) > struct xts_instance_ctx *ctx; > struct skcipher_alg *alg; > const char *cipher_name; > + u32 mask; > int err; > > algt = crypto_get_attr_type(tb); > @@ -483,18 +484,19 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb) > ctx = skcipher_instance_ctx(inst); > > crypto_set_skcipher_spawn(&ctx->spawn, skcipher_crypto_instance(inst)); > - err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0, > - crypto_requires_sync(algt->type, > - algt->mask)); > + > + mask = crypto_requires_sync(algt->type, algt->mask) | > + ((algt->type ^ CRYPTO_ALG_NEED_FALLBACK) & algt->mask & > + CRYPTO_ALG_NEED_FALLBACK); > + > + err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0, mask); > if (err == -ENOENT) { > err = -ENAMETOOLONG; > if (snprintf(ctx->name, CRYPTO_MAX_ALG_NAME, "ecb(%s)", > cipher_name) >= CRYPTO_MAX_ALG_NAME) > goto err_free_inst; > > - err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0, > - crypto_requires_sync(algt->type, > - algt->mask)); > + err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0, mask); > } > > if (err) > -- > 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 -- Regards, Marcelo [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup 2017-02-25 19:20 ` Marcelo Cerri @ 2017-02-26 4:22 ` Herbert Xu 2017-02-26 4:24 ` [v2 PATCH] crypto: xts - Propagate NEED_FALLBACK bit Herbert Xu 2017-02-26 19:14 ` crypto: hang in crypto_larval_lookup Harald Freudenberger 0 siblings, 2 replies; 13+ messages in thread From: Herbert Xu @ 2017-02-26 4:22 UTC (permalink / raw) To: Marcelo Cerri; +Cc: Harald Freudenberger, linux-crypto, schwidefsky On Sat, Feb 25, 2017 at 04:20:22PM -0300, Marcelo Cerri wrote: > > Yeah, I agree. This should work as long as the module aliases are > correct, which is enough. > > Other templates will not trigger the same error since they don't have to > try more than one underlying algorithm. But I think this is still > desirable for the remaining templates to avoid a long chain of unused > fallbacks as in the example I gave in my previous email. > > Probably a helper function to return the correct mask might be useful > for readability and to avoid duplicate code. You're right. Here is a patch to add a helper for this. Thanks! ---8<--- Subject: crypto: api - Add crypto_requires_off helper This patch adds crypto_requires_off which is an extension of crypto_requires_sync for similar bits such as NEED_FALLBACK. Suggested-by: Marcelo Cerri <marcelo.cerri@canonical.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h index ebe4ded..436c4c2 100644 --- a/include/crypto/algapi.h +++ b/include/crypto/algapi.h @@ -360,13 +360,18 @@ static inline struct crypto_alg *crypto_get_attr_alg(struct rtattr **tb, return crypto_attr_alg(tb[1], type, mask); } +static inline int crypto_requires_off(u32 type, u32 mask, u32 off) +{ + return (type ^ off) & mask & off; +} + /* * Returns CRYPTO_ALG_ASYNC if type/mask requires the use of sync algorithms. * Otherwise returns zero. */ static inline int crypto_requires_sync(u32 type, u32 mask) { - return (type ^ CRYPTO_ALG_ASYNC) & mask & CRYPTO_ALG_ASYNC; + return crypto_requires_off(type, mask, CRYPTO_ALG_ASYNC); } noinline unsigned long __crypto_memneq(const void *a, const void *b, size_t size); -- 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 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [v2 PATCH] crypto: xts - Propagate NEED_FALLBACK bit 2017-02-26 4:22 ` Herbert Xu @ 2017-02-26 4:24 ` Herbert Xu 2017-02-26 19:14 ` crypto: hang in crypto_larval_lookup Harald Freudenberger 1 sibling, 0 replies; 13+ messages in thread From: Herbert Xu @ 2017-02-26 4:24 UTC (permalink / raw) To: Marcelo Cerri; +Cc: Harald Freudenberger, linux-crypto, schwidefsky When we're used as a fallback algorithm, we should propagate the NEED_FALLBACK bit when searching for the underlying ECB mode. This just happens to fix a hang too because otherwise the search may end up loading the same module that triggered this XTS creation. Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher") Reported-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> diff --git a/crypto/xts.c b/crypto/xts.c index 410a2e2..baeb34d 100644 --- a/crypto/xts.c +++ b/crypto/xts.c @@ -463,6 +463,7 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb) struct xts_instance_ctx *ctx; struct skcipher_alg *alg; const char *cipher_name; + u32 mask; int err; algt = crypto_get_attr_type(tb); @@ -483,18 +484,19 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb) ctx = skcipher_instance_ctx(inst); crypto_set_skcipher_spawn(&ctx->spawn, skcipher_crypto_instance(inst)); - err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0, - crypto_requires_sync(algt->type, - algt->mask)); + + mask = crypto_requires_off(algt->type, algt->mask, + CRYPTO_ALG_NEED_FALLBACK | + CRYPTO_ALG_ASYNC); + + err = crypto_grab_skcipher(&ctx->spawn, cipher_name, 0, mask); if (err == -ENOENT) { err = -ENAMETOOLONG; if (snprintf(ctx->name, CRYPTO_MAX_ALG_NAME, "ecb(%s)", cipher_name) >= CRYPTO_MAX_ALG_NAME) goto err_free_inst; - err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0, - crypto_requires_sync(algt->type, - algt->mask)); + err = crypto_grab_skcipher(&ctx->spawn, ctx->name, 0, mask); } if (err) -- 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 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: crypto: hang in crypto_larval_lookup 2017-02-26 4:22 ` Herbert Xu 2017-02-26 4:24 ` [v2 PATCH] crypto: xts - Propagate NEED_FALLBACK bit Herbert Xu @ 2017-02-26 19:14 ` Harald Freudenberger 1 sibling, 0 replies; 13+ messages in thread From: Harald Freudenberger @ 2017-02-26 19:14 UTC (permalink / raw) To: Herbert Xu, Marcelo Cerri; +Cc: linux-crypto, Martin Schwidefsky On 02/26/2017 05:22 AM, Herbert Xu wrote: > On Sat, Feb 25, 2017 at 04:20:22PM -0300, Marcelo Cerri wrote: >> Yeah, I agree. This should work as long as the module aliases are >> correct, which is enough. >> >> Other templates will not trigger the same error since they don't have to >> try more than one underlying algorithm. But I think this is still >> desirable for the remaining templates to avoid a long chain of unused >> fallbacks as in the example I gave in my previous email. >> >> Probably a helper function to return the correct mask might be useful >> for readability and to avoid duplicate code. > You're right. Here is a patch to add a helper for this. > Thanks! > > ---8<--- > Subject: crypto: api - Add crypto_requires_off helper > > This patch adds crypto_requires_off which is an extension of > crypto_requires_sync for similar bits such as NEED_FALLBACK. > > Suggested-by: Marcelo Cerri <marcelo.cerri@canonical.com> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> > > diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h > index ebe4ded..436c4c2 100644 > --- a/include/crypto/algapi.h > +++ b/include/crypto/algapi.h > @@ -360,13 +360,18 @@ static inline struct crypto_alg *crypto_get_attr_alg(struct rtattr **tb, > return crypto_attr_alg(tb[1], type, mask); > } > > +static inline int crypto_requires_off(u32 type, u32 mask, u32 off) > +{ > + return (type ^ off) & mask & off; > +} > + > /* > * Returns CRYPTO_ALG_ASYNC if type/mask requires the use of sync algorithms. > * Otherwise returns zero. > */ > static inline int crypto_requires_sync(u32 type, u32 mask) > { > - return (type ^ CRYPTO_ALG_ASYNC) & mask & CRYPTO_ALG_ASYNC; > + return crypto_requires_off(type, mask, CRYPTO_ALG_ASYNC); > } > > noinline unsigned long __crypto_memneq(const void *a, const void *b, size_t size); applied the xts.c create patch v2 and the helper patch, built and installed. Now the aes_s390 module loads perfect without any hang, no complains in syslog and /proc/crypto shows that all selftests for the algs in the module passed successful. Thanks all for your help :-) regards, Harald Freudenberger ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-02-26 19:14 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-17 17:50 crypto: hang in crypto_larval_lookup Harald Freudenberger 2017-02-23 11:19 ` Herbert Xu 2017-02-23 11:39 ` Herbert Xu 2017-02-23 16:02 ` Harald Freudenberger 2017-02-24 8:42 ` Harald Freudenberger 2017-02-24 10:32 ` Harald Freudenberger 2017-02-24 11:21 ` Harald Freudenberger 2017-02-24 23:44 ` Marcelo Cerri 2017-02-25 15:17 ` Herbert Xu 2017-02-25 19:20 ` Marcelo Cerri 2017-02-26 4:22 ` Herbert Xu 2017-02-26 4:24 ` [v2 PATCH] crypto: xts - Propagate NEED_FALLBACK bit Herbert Xu 2017-02-26 19:14 ` crypto: hang in crypto_larval_lookup Harald Freudenberger
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).