Commit Graph

20 Commits

Author SHA1 Message Date
Cristian Stoica
5be4d4c94b crypto: replace scatterwalk_sg_next with sg_next
Modify crypto drivers to use the generic SG helper since
both of them are equivalent and the one from crypto is redundant.

See also:
  468577abe3   reverted in
  b2ab4a57b0

Signed-off-by: Cristian Stoica <cristian.stoica@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-01-26 11:34:22 +11:00
Joel Fernandes
257aff5154 crypto: scatterwalk - Add support for calculating number of SG elements
Crypto layer only passes nbytes to encrypt but in omap-aes driver we need to
know number of SG elements to pass to dmaengine slave API.  We add function for
the same to scatterwalk library.

Signed-off-by: Joel Fernandes <joelf@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-08-21 21:27:58 +10:00
Cong Wang
f0dfc0b0b7 crypto: remove the second argument of k[un]map_atomic()
Signed-off-by: Cong Wang <amwang@redhat.com>
2012-03-20 21:48:16 +08:00
David S. Miller
85c6201a80 crypto: scatterwalk - Fix scatterwalk_done() test
We are done with the scattergather entry when the walk offset goes
past sg->offset + sg->length, not when it crosses a page boundary.

There is a similarly queer test in the second half of
scatterwalk_pagedone() that probably needs some scrutiny.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-05-19 14:06:29 +10:00
Herbert Xu
4f3e797ad0 crypto: scatterwalk - Avoid flush_dcache_page on slab pages
It's illegal to call flush_dcache_page on slab pages on a number
of architectures.  So this patch avoids doing so if PageSlab is
true.

In future we can move the flush_dcache_page call to those page
cache users that actually need it.

Reported-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-02-09 14:30:25 +11:00
Herbert Xu
6e050778c5 [CRYPTO] scatterwalk: Handle zero nbytes in scatterwalk_map_and_copy
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 08:16:54 +11:00
Herbert Xu
b2ab4a57b0 [CRYPTO] scatterwalk: Restore custom sg chaining for now
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 08:16:33 +11:00
Herbert Xu
42c271c6c5 [CRYPTO] scatterwalk: Move scatterwalk.h to linux/crypto
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 08:16:32 +11:00
Herbert Xu
468577abe3 [CRYPTO] scatterwalk: Use generic scatterlist chaining
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>
2008-01-11 08:16:14 +11:00
Jens Axboe
78c2f0b8c2 [SG] Update crypto/ to sg helpers
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-10-22 19:40:16 +02:00
Jens Axboe
ab83407e9e crypto: don't pollute the global namespace with sg_next()
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-16 11:07:09 +02:00
Herbert Xu
70dec235d8 [CRYPTO] api: Kill crypto_km_types
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 16:55:44 -07:00
Herbert Xu
5fa0fea274 [CRYPTO] scatterwalk: Add scatterwalk_map_and_copy
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-10-10 16:55:42 -07:00
Herbert Xu
9f11672728 [CRYPTO] api: Flush the current page right than the next
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 12:58:20 +10:00
Herbert Xu
4ee531a3e6 [CRYPTO] api: Use the right value when advancing scatterwalk_copychunks
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-31 12:16:20 +10:00
J. Bruce Fields
f70ee5ec8f [CRYPTO] api: scatterwalk_copychunks() fails to advance through scatterlist
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
5c64097aa0, 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>
2007-03-21 08:50:12 +11:00
Herbert Xu
5c64097aa0 [CRYPTO] scatterwalk: Prepare for block ciphers
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-09-21 11:41:52 +10:00
Al Viro
1b8623545b [PATCH] remove bogus asm/bug.h includes.
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>
2006-02-07 20:56:35 -05:00
Herbert Xu
c774e93e21 [CRYPTO] Add plumbing for multi-block operations
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-07-06 13:51:31 -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