Sonny Rao <sonnyrao@xxxxxxxxxxxx> wrote: > Hi, I've been investigating an issue relating to hardware crypto which > is that when I enable the s5p-sss module for hardware cryptographic > acceleration on Samsung Exynos SoCs the in-kernel IPSec seems to > break, although cryptographic operations on filesystems/block devices > using this driver seem to work fine. > > Originally we were looking at an older kernel (3.8 with patches), but > I've now verified on linux-next from 20140612 (after 3.15) with a few > additional patches (to enable both s5p-sss and Exynos5420) that this > is still the case. > > It looks like what is happening in the kernel is that IPsec ends up > with this callstack > > esp_output()-> crypto_aead_givencrypt()-> > crypto_authenc_givencrypt()-> eseqiv_givencrypt() -> > crypto_ablkcipher_encrypt() > > > which calls into the s5p-sss driver and that is returning -EINPROGRESS > (or possibly -EBUSY), and that is passed all the way back up the call > stack and that seems to be treated as an error condition by the ipsec > stack. > > For example esp_output does this: > > err = crypto_aead_givencrypt(req); > if (err == -EINPROGRESS) > goto error; > > if (err == -EBUSY) > err = NET_XMIT_DROP; > > So, I'm not sure how this is supposed to work, or if s5p-sss is doing > something wrong. Something else must be happening because EINPROGRESS is meant to be handled by xfrm_output_resume (which gets called on the normal path as well as on the actual resume path). So I don't think this is your problem. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
