summaryrefslogtreecommitdiff
path: root/crypto/deflate.c
Commit message (Collapse)AuthorAgeFilesLines
* crypto: prefix module autoloading with "crypto-"Kees Cook2014-11-241-1/+1
| | | | | | | | | | | This prefixes all crypto module loading with "crypto-" so we never run the risk of exposing module auto-loading to userspace via a crypto API, as demonstrated by Mathias Krause: https://lkml.org/lkml/2013/3/4/70 Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: cleanup - remove unneeded crypto_alg.cra_list initializationsJussi Kivilinna2012-08-011-1/+0
| | | | | | | | | | | Initialization of cra_list is currently mixed, most ciphers initialize this field and most shashes do not. Initialization however is not needed at all since cra_list is initialized/overwritten in __crypto_register_alg() with list_add(). Therefore perform cleanup to remove all unneeded initializations of this field in 'crypto/'. Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* net+crypto: Use vmalloc for zlib inflate buffers.David S. Miller2011-06-291-4/+3
| | | | | | | | | | | They are 64K and result in order-4 allocations, even with SLUB. Therefore, just like we always have for the deflate buffers, use vmalloc. Reported-by: Martin Jackson <mjackson220.list@gmail.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* zlib: slim down zlib_deflate() workspace when possibleJim Keniston2011-03-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | Instead of always creating a huge (268K) deflate_workspace with the maximum compression parameters (windowBits=15, memLevel=8), allow the caller to obtain a smaller workspace by specifying smaller parameter values. For example, when capturing oops and panic reports to a medium with limited capacity, such as NVRAM, compression may be the only way to capture the whole report. In this case, a small workspace (24K works fine) is a win, whether you allocate the workspace when you need it (i.e., during an oops or panic) or at boot time. I've verified that this patch works with all accepted values of windowBits (positive and negative), memLevel, and compression level. Signed-off-by: Jim Keniston <jkenisto@us.ibm.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: David Miller <davem@davemloft.net> Cc: Chris Mason <chris.mason@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* crypto: Use vzallocJoe Perches2010-11-271-2/+1
| | | | | Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: deflate - Fix checkpatch errorsRichard Hartmann2010-02-161-10/+10
| | | | | Signed-off-by: Richard Hartmann <richih.mailinglist@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] all: Clean up init()/fini()Kamalesh Babulal2008-04-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote: > Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote: > > > This patch cleanups the crypto code, replaces the init() and fini() > > with the <algorithm name>_init/_fini > > This part ist OK. > > > or init/fini_<algorithm name> (if the > > <algorithm name>_init/_fini exist) > > Having init_foo and foo_init won't be a good thing, will it? I'd start > confusing them. > > What about foo_modinit instead? Thanks for the suggestion, the init() is replaced with <algorithm name>_mod_init () and fini () is replaced with <algorithm name>_mod_fini. Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] api: Added cra_init/cra_exitHerbert Xu2006-06-261-2/+2
| | | | | | | | | | | | | | | This patch adds the hooks cra_init/cra_exit which are called during a tfm's construction and destruction respectively. This will be used by the instances to allocate child tfm's. For now this lets us get rid of the coa_init/coa_exit functions which are used for exactly that purpose (unlike the dia_init function which is called for each transaction). In fact the coa_exit path is currently buggy as it may get called twice when an error is encountered during initialisation. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] all: Pass tfm instead of ctx to algorithmsHerbert Xu2006-06-261-8/+11
| | | | | | | | | | | | | | | | Up until now algorithms have been happy to get a context pointer since they know everything that's in the tfm already (e.g., alignment, block size). However, once we have parameterised algorithms, such information will be specific to each tfm. So the algorithm API needs to be changed to pass the tfm structure instead of the context pointer. This patch is basically a text substitution. The only tricky bit is the assembly routines that need to get the context pointer offset through asm-offsets.h. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] all: Use kzalloc where possibleEric Sesterhenn2006-03-211-2/+1
| | | | | | | | this patch converts crypto/ to kzalloc usage. Compile tested with allyesconfig. Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [PATCH] crypto: call zlib end functions on deflate exit pathArtem B. Bityuckiy2005-04-161-0/+2
| | | | | | | | | | | | | | 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>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+223
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!