Commit graph

506 commits

Author SHA1 Message Date
Herbert Xu
ef2736fc74 [CRYPTO]: White space and coding style clean up in tcrypt
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-22 13:26:03 -07:00
Herbert Xu
15333038d5 [CRYPTO]: Only reschedule if !in_atomic()
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 <davem@davemloft.net>
2005-05-23 12:36:25 -07:00
Patrick McHardy
d0856009db [PATCH] crypto: fix null encryption/compression
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 <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-17 07:59:18 -07:00
Paolo 'Blaisorblade' Giarrusso
c45166be3c [PATCH] uml: support AES i586 crypto driver
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 <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01 08:58:54 -07:00
Artem B. Bityuckiy
9ffb7146f0 [PATCH] crypto: call zlib end functions on deflate exit path
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 <dedekind@infradead.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:23:58 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00