The VIA Padlock device is able to perform much better when multiple
blocks are fed to it at once.  As this device offers an exceptional
throughput rate it is worthwhile to optimise the infrastructure
specifically for it.

We shift the existing page-sized fast path down to the CBC/ECB functions.
We can then replace the CBC/ECB functions with functions provided by the
underlying algorithm that performs the multi-block operations.

As a side-effect this improves the performance of large cipher operations
for all existing algorithm implementations.  I've measured the gain to be
around 5% for 3DES and 15% for AES.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Checking a pointer for NULL before calling kfree() on it is redundant.
This patch removes such checks from crypto/
Signed-off-by: NJesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After using this facility for a while to test my changes to the
cipher crypt() layer, I realised that I should've listend to Dave
and made this thing use CPU cycle counters :) As it is it's too
jittery for me to feel safe about relying on the results.

So here is a patch to make it use CPU cycles by default but fall
back to jiffies if the user specifies a non-zero sec value.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The existing keys used in the speed tests do not pass the 3DES quality check.
This patch makes it use the template keys instead.

Other algorithms can supply template keys through the same interface if needed.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

From: Reyk Floeter <reyk@vantronix.net>

I recently had the requirement to do some benchmarking on cryptoapi, and
I found reyk's very useful performance test patch [1].

However, I could not find any discussion on why that extension (or
something providing a similar feature but different implementation) was
not merged into mainline.  If there was such a discussion, can someone
please point me to the archive[s]?

I've now merged the old patch into 2.6.12-rc1, the result can be found
attached to this email.

[1] http://lists.logix.cz/pipermail/padlock/2004/000010.htmlSigned-off-by: NHarald Welte <laforge@gnumonks.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It seems that bad code tends to get copied (see test_cipher_speed).  So let's
kill this idiom before it spreads any further.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The netlink gfp_any() problem made me double-check the uses of in_softirq()
in crypto/*.  It seems to me that we should be checking in_atomic() instead
of in_softirq() in crypto_yield.  Otherwise people calling the crypto ops
with spin locks held or preemption disabled will get burnt, right?
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

null_encrypt() needs to copy the data in case src and dst are disjunct,
null_compress() needs to copy the data in any case as far as I can tell.  I
joined compress/decompress and encrypt/decrypt to avoid duplicating code.

Without this patch ESP null_enc packets look like this:

IP (tos 0x0, ttl  64, id 23130, offset 0, flags [DF], length: 128)
10.0.0.1 > 10.0.0.2: ESP(spi=0x0f9ca149,seq=0x4)
	0x0000:  4500 0080 5a5a 4000 4032 cbef 0a00 0001  E...ZZ@.@2......
	0x0010:  0a00 0002 0f9c a149 0000 0004 0000 0000  .......I........
	0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
	0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
	0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................
	0x0050:  0000                                     ..

IP (tos 0x0, ttl  64, id 256, offset 0, flags [DF], length: 128)
10.0.0.2 > 10.0.0.1: ESP(spi=0x0e4f7b51,seq=0x2)
	0x0000:  4500 0080 0100 4000 4032 254a 0a00 0002  E.....@.@2%J....
	0x0010:  0a00 0001 0e4f 7b51 0000 0002 a8a8 a8a8  .....O{Q........
	0x0020:  a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8  ................
	0x0030:  a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8  ................
	0x0040:  a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8  ................
	0x0050:  a8a8                                     ..
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We want to make possible, for the user, to enable the i586 AES implementation.
This requires a restructure.

- Add a CONFIG_UML_X86 to notify that we are building a UML for i386.

- Rename CONFIG_64_BIT to CONFIG_64BIT as is used for all other archs

- Tell crypto/Kconfig that UML_X86 is as good as X86

- Tell it that it must exclude not X86_64 but 64BIT, which will give the
  same results.

- Tell kbuild to descend down into arch/i386/crypto/ to build what's needed.
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In the deflate_[compress|uncompress|pcompress] functions we call the
zlib_[in|de]flateReset function at the beginning.  This is OK.  But when we
unload the deflate module we don't call zlib_[in|de]flateEnd to free all
the zlib internal data.  It looks like a bug for me.  Please, consider the
attached patch.
Signed-off-by: NArtem B. Bityuckiy <dedekind@infradead.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!