23 Jun, 2005
5 commits
-
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: Herbert Xu
Signed-off-by: David S. Miller -
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: Herbert Xu
Signed-off-by: David S. Miller -
From: Reyk Floeter
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.html
Signed-off-by: Harald Welte
Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller -
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: Herbert Xu
Signed-off-by: David S. Miller -
Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller
24 May, 2005
1 commit
-
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: David S. Miller
17 May, 2005
1 commit
-
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: Patrick McHardy
Signed-off-by: Herbert Xu
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 May, 2005
1 commit
-
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: Paolo 'Blaisorblade' Giarrusso
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Apr, 2005
2 commits
-
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: Artem B. Bityuckiy
Signed-off-by: Herbert Xu
Cc: "David S. Miller"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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!
