Kent Borg <kentborg@xxxxxxxx> wrote:
>
> Maybe both modules are processing the data-in/data-out aspect correctly,
> but are misbehaving in some other way; a missing lock on a critical
> section, for example. For some reason IPSec gets unhappy where self-test
> and loopback are quite content. Or, maybe IPSec has a bug that is
> somehow exposed when a different HW unit gets into the act. (Which is
> why I was looking for any confirmed case of IPSec going through the
> kernel's crypto infrastructure for HW acceleration.)
That is entirely possible.
One way to test whether this is a bug in IPsec or crypto is to
instantiate a cryptd instance on sha by using cryptd(sha1-generic).
If that works then it's probably a bug in your driver, otherwise
we may have an issue in IPsec itself.
Thanks!
--
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
[Kernel]
[Gnu Classpath]
[Gnu Crypto]
[DM Crypt]
[Netfilter]
[Bugtraq]