summaryrefslogtreecommitdiffstats
path: root/crypto/scatterwalk.c
AgeCommit message (Collapse)AuthorFilesLines
2008-01-11[CRYPTO] scatterwalk: Handle zero nbytes in scatterwalk_map_and_copyHerbert Xu1-0/+3
It's better to return silently than crash and burn when someone feeds us a zero length. In particular the null digest algorithm when used as part of authenc will do that to us. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-01-11[CRYPTO] scatterwalk: Restore custom sg chaining for nowHerbert Xu1-2/+2
Unfortunately the generic chaining hasn't been ported to all architectures yet, and notably not s390. So this patch restores the chainging that we've been using previously which does work everywhere. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-01-11[CRYPTO] scatterwalk: Move scatterwalk.h to linux/cryptoHerbert Xu1-3/+2
The scatterwalk infrastructure is used by algorithms so it needs to move out of crypto for future users that may live in drivers/crypto or asm/*/crypto. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-01-11[CRYPTO] scatterwalk: Use generic scatterlist chainingHerbert Xu1-1/+1
This patch converts the crypto scatterwalk code to use the generic scatterlist chaining rather the version specific to crypto. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-10-22[SG] Update crypto/ to sg helpersJens Axboe1-1/+1
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-10-16crypto: don't pollute the global namespace with sg_next()Jens Axboe1-1/+1
It's a subsystem function, prefix it as such. Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-10-10[CRYPTO] api: Kill crypto_km_typesHerbert Xu1-8/+0
When scatterwalk is built as a module digest.c was broken because it requires the crypto_km_types structure which is in scatterwalk. This patch removes the crypto_km_types structure by encoding the logic into crypto_kmap_type directly. In fact, this even saves a few bytes of code (not to mention the data structure itself) on i386 which is about the only place where it's needed. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-10-10[CRYPTO] scatterwalk: Add scatterwalk_map_and_copyHerbert Xu1-0/+22
This patch adds the function scatterwalk_map_and_copy which reads or writes a chunk of data from a scatterlist at a given offset. It will be used by authenc which would read/write the authentication data at the end of the cipher/plain text. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-03-31[CRYPTO] api: Flush the current page right than the nextHerbert Xu1-2/+6
On platforms where flush_dcache_page is needed we're currently flushing the next page right than the one we've just processed. This patch fixes the off-by-one error. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-03-31[CRYPTO] api: Use the right value when advancing scatterwalk_copychunksHerbert Xu1-1/+1
In the scatterwalk_copychunks loop, We should be advancing by len_this_page and not nbytes. The latter is the total length. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-03-21[CRYPTO] api: scatterwalk_copychunks() fails to advance through scatterlistJ. Bruce Fields1-2/+2
In the loop in scatterwalk_copychunks(), if walk->offset is zero, then scatterwalk_pagedone rounds that up to the nearest page boundary: walk->offset += PAGE_SIZE - 1; walk->offset &= PAGE_MASK; which is a no-op in this case, so we don't advance to the next element of the scatterlist array: if (walk->offset >= walk->sg->offset + walk->sg->length) scatterwalk_start(walk, sg_next(walk->sg)); and we end up copying the same data twice. It appears that other callers of scatterwalk_{page}done first advance walk->offset, so I believe that's the correct thing to do here. This caused a bug in NFS when run with krb5p security, which would cause some writes to fail with permissions errors--for example, writes of less than 8 bytes (the des blocksize) at the start of a file. A git-bisect shows the bug was originally introduced by 5c64097aa0f6dc4f27718ef47ca9a12538d62860, first in 2.6.19-rc1. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21[CRYPTO] scatterwalk: Prepare for block ciphersHerbert Xu1-49/+40
This patch prepares the scatterwalk code for use by the new block cipher type. Firstly it halves the size of scatter_walk on 32-bit platforms. This is important as we allocate at least two of these objects on the stack for each block cipher operation. It also exports the symbols since the block cipher code can be built as a module. Finally there is a hack in scatterwalk_unmap that relies on progress being made. Unfortunately, for hardware crypto we can't guarantee progress to be made since the hardware can fail. So this also gets rid of the hack by not advancing the address returned by scatterwalk_map. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-02-07[PATCH] remove bogus asm/bug.h includes.Al Viro1-1/+0
A bunch of asm/bug.h includes are both not needed (since it will get pulled anyway) and bogus (since they are done too early). Removed. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2005-07-06[CRYPTO] Add plumbing for multi-block operationsHerbert Xu1-2/+2
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: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+115
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!