- 17 8月, 2015 1 次提交
-
-
由 Dan Williams 提交于
Signed-off-by: NDan Williams <dan.j.williams@intel.com> [hch: split from a larger patch by Dan] Signed-off-by: NChristoph Hellwig <hch@lst.de> Acked-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NJens Axboe <axboe@fb.com>
-
- 22 5月, 2015 1 次提交
-
-
由 Herbert Xu 提交于
This patch adds the scatterwalk_ffwd helper which can create an SG list that starts in the middle of an existing SG list. The new list may either be part of the existing list or be a chain that latches onto part of the existing list. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 26 1月, 2015 1 次提交
-
-
由 Cristian Stoica 提交于
Modify crypto drivers to use the generic SG helper since both of them are equivalent and the one from crypto is redundant. See also: 468577ab reverted in b2ab4a57Signed-off-by: NCristian Stoica <cristian.stoica@freescale.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 20 6月, 2014 1 次提交
-
-
由 Marek Vasut 提交于
It makes no sense for crypto_yield() to be defined in scatterwalk.h , move it into algapi.h as it's an internal function to crypto API. Signed-off-by: NMarek Vasut <marex@denx.de> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 09 12月, 2013 1 次提交
-
-
由 Tom Lendacky 提交于
Now that scatterwalk_sg_chain sets the chain pointer bit the sg_page call in scatterwalk_sg_next hits a BUG_ON when CONFIG_DEBUG_SG is enabled. Use sg_chain_ptr instead of sg_page on a chain entry. Cc: stable@vger.kernel.org Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 28 11月, 2013 1 次提交
-
-
由 Tom Lendacky 提交于
The scatterwalk_crypto_chain function invokes the scatterwalk_sg_chain function to chain two scatterlists, but the chain pointer indication bit is not set. When the resulting scatterlist is used, for example, by sg_nents to count the number of scatterlist entries, a segfault occurs because sg_nents does not follow the chain pointer to the chained scatterlist. Update scatterwalk_sg_chain to set the chain pointer indication bit as is done by the sg_chain function. Cc: stable@vger.kernel.org Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 21 8月, 2013 1 次提交
-
-
由 Joel Fernandes 提交于
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: NJoel Fernandes <joelf@ti.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 20 3月, 2012 1 次提交
-
-
由 Cong Wang 提交于
Signed-off-by: NCong Wang <amwang@redhat.com>
-
- 02 12月, 2010 1 次提交
-
-
由 Steffen Klassert 提交于
A lot of crypto algorithms implement their own chaining function. So add a generic one that can be used from all the algorithms that need scatterlist chaining. Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 01 5月, 2008 1 次提交
-
-
由 Herbert Xu 提交于
When I backed out of using the generic sg chaining (as it isn't currently portable) and introduced scatterwalk_sg_chain/scatterwalk_sg_next I left out the sg_is_last check in the latter. This causes it to potentially dereference beyond the end of the sg array. As most uses of scatterwalk_sg_next are bound by an overall length, this only affected the chaining code in authenc and eseqiv. Thanks to Patrick McHardy for identifying this problem. This patch also clears the "last" bit on the head of the chained list as it's no longer last. This also went missing in scatterwalk_sg_chain and is present in sg_chain. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 11 1月, 2008 4 次提交
-
-
由 Herbert Xu 提交于
As Andrew Morton correctly points out, we need to explicitly include sched.h as we use the function cond_resched in crypto/scatterwalk.h. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Herbert Xu 提交于
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: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Herbert Xu 提交于
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: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Herbert Xu 提交于
This patch converts the crypto scatterwalk code to use the generic scatterlist chaining rather the version specific to crypto. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 23 10月, 2007 1 次提交
-
-
由 Jens Axboe 提交于
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
-
- 16 10月, 2007 1 次提交
-
-
由 Jens Axboe 提交于
It's a subsystem function, prefix it as such. Acked-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
-
- 11 10月, 2007 1 次提交
-
-
由 Herbert Xu 提交于
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: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 21 9月, 2006 2 次提交
-
-
由 Herbert Xu 提交于
The existing digest user interface is inadequate for support asynchronous operations. For one it doesn't return a value to indicate success or failure, nor does it take a per-operation descriptor which is essential for the issuing of requests while other requests are still outstanding. This patch is the first in a series of steps to remodel the interface for asynchronous operations. For the ease of transition the new interface will be known as "hash" while the old one will remain as "digest". This patch also changes sg_next to allow chaining. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Herbert Xu 提交于
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: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 07 7月, 2005 2 次提交
-
-
由 Herbert Xu 提交于
The VIA Padlock device requires the input and output buffers to be aligned on 16-byte boundaries. This patch adds the alignmask attribute for low-level cipher implementations to indicate their alignment requirements. The mid-level crypt() function will copy the input/output buffers if they are not aligned correctly before they are passed to the low-level implementation. Strictly speaking, some of the software implementations require the buffers to be aligned on 4-byte boundaries as they do 32-bit loads. However, it is not clear whether it is better to copy the buffers or pay the penalty for unaligned loads/stores. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Herbert Xu 提交于
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: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 17 4月, 2005 1 次提交
-
-
由 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!
-