Re: linux-next: Tree for Jun 13 (crypto)

[Jussi Kivilinna]

Quoting Johannes Goetzfried  
<Johannes.Goetzfried@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>:

> On Wed, Jun 13, 2012 at 08:03:17PM +0300, Jussi Kivilinna wrote:
> > >arch/x86/crypto/serpent-avx-x86_64.o: In function `serpent_xts_decrypt':
> > >(.text+0x856c): multiple definition of `serpent_xts_decrypt'
> > >arch/x86/crypto/serpent-sse2-x86_64.o:(.text+0xae8): first defined here
> >
> > Reverting commit e2f4d85d5b2049a90859aa10de914ed31a4f17a4, "crypto:
> > serpent - add common glue code for avx and sse2 implementation",
> > should help for most.
> >
> > >arch/x86/crypto/serpent-avx-x86_64.o: In function `serpent_dec_blk_8way':
> > >(.text+0x3d70): multiple definition of `serpent_dec_blk_8way'
> > >arch/x86/crypto/serpent-avx-x86_64.o: In function `__serpent_enc_blk_8way':
> > >(.text+0x0): multiple definition of `__serpent_enc_blk_8way'
> >
> > Attached patch should solve these (patch depends on above revert).
>
> I'm really sorry about this, it shouldn't have happened. The most easiest
> solution to this problem would be to make the choice between
> CRYPTO_SERPENT_SSE2_X86_64 and CRYPTO_SERPENT_AVX_X86_64 an  
> exclusive-or choice
> in crypto/Kconfig. I don't think there is an use-case, where somebody would
> want to link both implementations into the same kernel image or even  
> load both
> implementations as module. This would avoid duplicating the glue-code again.

I'd think that most common use-case is distro-kernel, where all and  
everything is enabled by default.

> Another possibility would be to add a serpent-common-x86_64 module, but this
> wouldn't be a trivial change and imo a little bit too much just to avoid
> duplicating this code.

I'm working on patch-set that takes common glue code from  
serpent-sse2, serpent-avx, twofish-3way, twofish-avx and  
camellia-x86_64, to shared ablk_helper and glue_helper modules.

-Jussi



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/