Fix the "DMA-API: device driver maps memory from stack" warning
generated when crypto accelerators map the IV.
Signed-off-by: Horia Geantă
---
crypto/testmgr.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 500a5277cc22..64245a
Some hardware accelerators (like intel aseni or the s390
cpacf functions) have lower priorities than virtio
crypto, and those drivers are faster than the same in
the host via virtio. So let's lower the priority of
virtio-crypto's algorithm, make it's higher than sofeware
implimentations but lower t
On Thu, Jan 12, 2017 at 08:37:18PM -0800, Linus Torvalds wrote:
> On Jan 12, 2017 8:28 PM, "Josh Poimboeuf" wrote:
>
>
> The stack frame was always 16-byte aligned regardless of whether the
> buf array size was even or odd.
>
>
> Including with -fomit-frame-pointer?
>
> With frame pointers, s
On Thu, Jan 12, 2017 at 07:23:18PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 12, 2017 at 7:11 PM, Josh Poimboeuf wrote:
> > On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote:
> >> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf
> >> wrote:
> >> > On Thu, Jan 12, 2017 at 12:08:07
On Thu, Jan 12, 2017 at 7:11 PM, Josh Poimboeuf wrote:
> On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote:
>> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf wrote:
>> > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
>> >> On Thu, Jan 12, 2017 at 11:51 AM, Linus
On Thu, Jan 12, 2017 at 01:59:57PM +0100, Ondrej Mosnacek wrote:
> This patch implements bulk request handling in the AES-NI crypto drivers.
> The major advantage of this is that with bulk requests, the kernel_fpu_*
> functions (which are usually quite slow) are now called only once for the
> whol
On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf wrote:
> > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
> >> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
> >> wrote:
> >> > On Thu, Jan 12, 2017 at 6:02 AM,
>
> On Thu, Jan 12, 2017 at 03:10:25PM +0100, Christian Borntraeger wrote:
> > On 01/10/2017 01:56 PM, Christian Borntraeger wrote:
> > > On 01/10/2017 01:36 PM, Gonglei (Arei) wrote:
> > >> Hi,
> > >>
> > >>>
> > >>> On 12/15/2016 03:03 AM, Gonglei wrote:
> > >>> [...]
> > +
> > +static
On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf wrote:
> On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
>> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
>> wrote:
>> > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf
>> > wrote:
>> >>
>> >> Just to clarify, I think you're a
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 1abee99eafab67fb1c98f9ecfc43cd5735384a86
commit: 81edb42629758bacdf813dd5e4542ae26e3ad73a [43/44] crypto: arm/aes -
replace scalar AES cipher
config: arm-allmodconfig (attached as .config)
compiler: a
On Thu, Jan 12, 2017 at 12:55 PM, Josh Poimboeuf wrote:
>
> - Who's going to run sparse all the time to catch unauthorized users of
> __aligned__(16)?
Well, considering that we apparently only have a small handful of
existing users without anybody having ever run any tool at all, I
don't think
On Thu, Jan 12, 2017 at 02:15:11PM -0600, Josh Poimboeuf wrote:
> On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
> > On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
> > wrote:
> > > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf
> > > wrote:
> > >>
> > >> Just to clarify, I t
Hi Arnd,
On 12 January 2017 at 19:04, kbuild test robot wrote:
> tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
> master
> head: 1abee99eafab67fb1c98f9ecfc43cd5735384a86
> commit: 81edb42629758bacdf813dd5e4542ae26e3ad73a [43/44] crypto: arm/aes -
> replac
On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
> wrote:
> > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf wrote:
> >>
> >> Just to clarify, I think you're asking if, for versions of gcc which
> >> don't support -mpreferred-sta
On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
wrote:
> On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf wrote:
>>
>> Just to clarify, I think you're asking if, for versions of gcc which
>> don't support -mpreferred-stack-boundary=3, objtool can analyze all C
>> functions to ensure their stacks
On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf wrote:
>
> Just to clarify, I think you're asking if, for versions of gcc which
> don't support -mpreferred-stack-boundary=3, objtool can analyze all C
> functions to ensure their stacks are 16-byte aligned.
>
> It's certainly possible, but I don't s
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 1abee99eafab67fb1c98f9ecfc43cd5735384a86
commit: 81edb42629758bacdf813dd5e4542ae26e3ad73a [43/44] crypto: arm/aes -
replace scalar AES cipher
config: arm-multi_v7_defconfig (attached as .config)
compi
Commit c1e9b3b0eea1 ("hwrng: n2 - Attach on T5/M5, T7/M7 SPARC CPUs")
added config strings to enable the random number generator in the sparc
m5 and m7 platforms. This worked fine for client LDoms, but not for the
primary LDom, or running on bare metal, because the actual rng hardware
layout chang
Signed-off-by: Shannon Nelson
---
drivers/char/hw_random/n2-drv.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/hw_random/n2-drv.c b/drivers/char/hw_random/n2-drv.c
index f0bd5ee..31cbdbb 100644
--- a/drivers/char/hw_random/n2-drv.c
+++ b/drivers/cha
If the self-test fails, it probably won't actually suddenly
start working. Currently, this causes an endless spew of
error messages on the console and in the logs, so this patch
adds a limiter to the test.
Reported-by: Sowmini Varadhan
Signed-off-by: Shannon Nelson
---
drivers/char/hw_random/n
Since we're going to need to keep track of more than just one
attribute of the hardware, we'll change the use of the data field
from the match struct from a single flag to a struct pointer.
This patch adds the struct template and initial descriptions.
Signed-off-by: Shannon Nelson
---
drivers/ch
Add the new register layout constants and the requisite logic
for using them.
Signed-off-by: Shannon Nelson
---
drivers/char/hw_random/n2-drv.c | 144 +--
drivers/char/hw_random/n2rng.h | 36 +++---
2 files changed, 134 insertions(+), 46 deletions(-)
On Thu, Jan 12, 2017 at 10:08:46PM +0530, Harsh Jain wrote:
>
> That case is already handled in next if condition.It will error out with
> -EINVAL in next condition.
>
> if (keylen == AES_KEYSIZE_128) {
Good point. Please split the patches according to whether they
should go into 4.10/4.11 and
On 12 January 2017 at 16:45, Herbert Xu wrote:
> On Wed, Jan 11, 2017 at 04:41:48PM +, Ard Biesheuvel wrote:
>> This adds ARM and arm64 implementations of ChaCha20, scalar AES and SIMD
>> AES (using bit slicing). The SIMD algorithms in this series take advantage
>> of the new skcipher walksize
On Wed, Jan 11, 2017 at 02:55:20PM +0100, Arnd Bergmann wrote:
> After I enabled COMPILE_TEST for non-ARM targets, I ran into these
> warnings:
>
> crypto/mediatek/mtk-aes.c: In function 'mtk_aes_info_map':
> crypto/mediatek/mtk-aes.c:224:28: error: format '%d' expects argument of type
> 'int', b
On Wed, Jan 11, 2017 at 04:41:48PM +, Ard Biesheuvel wrote:
> This adds ARM and arm64 implementations of ChaCha20, scalar AES and SIMD
> AES (using bit slicing). The SIMD algorithms in this series take advantage
> of the new skcipher walksize attribute to iterate over the input in the most
> ef
On Wed, Jan 11, 2017 at 02:50:19PM +0100, Arnd Bergmann wrote:
> Building the mediatek driver on an older ARM architecture results in a
> harmless warning:
>
> warning: (ARCH_OMAP2PLUS_TYPICAL && CRYPTO_DEV_MEDIATEK) selects NEON which
> has unmet direct dependencies (VFPv3 && CPU_V7)
>
> We cou
On Tue, Jan 10, 2017 at 03:24:46PM -0800, Andy Lutomirski wrote:
> There are some hashes (e.g. sha224) that have some internal trickery
> to make sure that only the correct number of output bytes are
> generated. If something goes wrong, they could potentially overrun
> the output buffer.
>
> Mak
On Tue, Jan 03, 2017 at 01:21:22PM +, Colin King wrote:
> From: Colin Ian King
>
> In the case where keylen <= bs mtk_sha_setkey returns an uninitialized
> return value in err. Fix this by returning 0 instead of err.
>
> Issue detected by static analysis with cppcheck.
>
> Signed-off-by: C
On Mon, Jan 02, 2017 at 02:06:56PM -0300, Javier Martinez Canillas wrote:
> Hello,
>
> This small series contains a couple of cleanups that removes some driver's
> code
> that isn't needed due the driver being for a DT-only platform.
>
> The changes were suggested by Arnd Bergmann as a response
On Sat, Dec 31, 2016 at 09:26:23PM +0530, gidisr...@gmail.com wrote:
> From: Gideon Israel Dsouza
>
> Continuing from this commit: 52f5684c8e1e
> ("kernel: use macros from compiler.h instead of __attribute__((...))")
>
> I submitted 4 total patches. They are part of task I've taken up to
> incre
On Fri, Dec 30, 2016 at 02:12:00PM -0600, Eric Biggers wrote:
> From: Eric Biggers
>
> It's recommended to use kmemdup instead of kmalloc followed by memcpy.
>
> Signed-off-by: Eric Biggers
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
On 12-01-2017 21:39, Herbert Xu wrote:
> On Fri, Jan 06, 2017 at 02:01:34PM +0530, Harsh Jain wrote:
>> Check keylen before copying salt to avoid wrap around of Integer.
>>
>> Signed-off-by: Harsh Jain
>> ---
>> drivers/crypto/chelsio/chcr_algo.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2
Am Freitag, 13. Januar 2017, 00:06:29 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 05:01:13PM +0100, Stephan Müller wrote:
> > I fully agree. Therefore, I was under the impression that disregarding the
> > AAD in recvmsg entirely would be most appropriate as offered with the
> >
On Thu, Jan 12, 2017 at 04:50:46PM +0100, Stephan Müller wrote:
>
> So you say that we could remove it from authenc() entirely (this is currently
> the only location where such copy operation is found for the encryption
> direction)?
>
> I would concur that the kernel does not need that.
authen
On Sat, Jan 07, 2017 at 10:46:17AM +0100, Julia Lawall wrote:
> The first argument to list_for_each_entry cannot be NULL.
>
> Generated by: scripts/coccinelle/iterators/itnull.cocci
>
> CC: Harsh Jain
> Signed-off-by: Julia Lawall
> Signed-off-by: Fengguang Wu
> ---
>
> This code comes from t
Am Freitag, 13. Januar 2017, 00:17:59 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 05:10:14PM +0100, Stephan Müller wrote:
> > Each IOCB would transpire into an independent, separate recvmsg invocation
> > without an additional sendmsg/sendpage operation. Thus, in order to
> > su
On Thu, Jan 12, 2017 at 05:10:14PM +0100, Stephan Müller wrote:
>
> Each IOCB would transpire into an independent, separate recvmsg invocation
> without an additional sendmsg/sendpage operation. Thus, in order to support
> multiple IOCBs, all data the multiple recvmsg invocations will operate on
On Fri, Jan 06, 2017 at 02:01:31PM +0530, Harsh Jain wrote:
> The patch series is based on Herbert's cryptodev-2.6 tree.
> It include bug fixes.
>
> Atul Gupta (4):
> crypto:chcr-Change flow IDs
> crypto:chcr- Fix panic on dma_unmap_sg
> crypto:chcr- Check device is allocated before use
>
Am Freitag, 13. Januar 2017, 00:07:39 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 05:05:03PM +0100, Stephan Müller wrote:
> > Am Donnerstag, 12. Januar 2017, 16:56:04 CET schrieb Stephan Müller:
> >
> > Hi Herbert,
> >
> > > That would mean that we would only support one IOCB.
On Fri, Jan 06, 2017 at 02:01:34PM +0530, Harsh Jain wrote:
> Check keylen before copying salt to avoid wrap around of Integer.
>
> Signed-off-by: Harsh Jain
> ---
> drivers/crypto/chelsio/chcr_algo.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/ch
On Thu, Jan 12, 2017 at 05:05:03PM +0100, Stephan Müller wrote:
> Am Donnerstag, 12. Januar 2017, 16:56:04 CET schrieb Stephan Müller:
>
> Hi Herbert,
>
> >
> > That would mean that we would only support one IOCB.
>
> As we also need to be standards compliant, would it be appropriate to only
>
On Thu, Jan 12, 2017 at 05:01:13PM +0100, Stephan Müller wrote:
>
> I fully agree. Therefore, I was under the impression that disregarding the
> AAD
> in recvmsg entirely would be most appropriate as offered with the patch
> "crypto: AF_ALG - disregard AAD buffer space for output". In this case
Am Donnerstag, 12. Januar 2017, 16:56:04 CET schrieb Stephan Müller:
Hi Herbert,
>
> That would mean that we would only support one IOCB.
As we also need to be standards compliant, would it be appropriate to only
support one IOCB? I think this is a significant difference to other AIO
operatio
Am Donnerstag, 12. Januar 2017, 23:53:44 CET schrieb Herbert Xu:
Hi Herbert,
>
> > If we only want to solve that for algif_aead, wouldn't it make more sense
> > if the user space caller takes care of that (such as libkcapi)? By
> > tinkering with the SGLs and copying the data to the dst buffer b
Am Donnerstag, 12. Januar 2017, 23:51:28 CET schrieb Herbert Xu:
Hi Herbert,
> On Sun, Dec 25, 2016 at 06:15:06PM +0100, Stephan Müller wrote:
> > + * The following concept of the memory management is used:
> > + *
> > + * The kernel maintains two SGLs, the TX SGL and the RX SGL. The TX SGL
> > i
On Sun, Dec 25, 2016 at 06:15:06PM +0100, Stephan Müller wrote:
>
> + * The following concept of the memory management is used:
> + *
> + * The kernel maintains two SGLs, the TX SGL and the RX SGL. The TX SGL is
> + * filled by user space with the data submitted via sendpage/sendmsg. Filling
> + *
Am Donnerstag, 12. Januar 2017, 23:39:24 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 04:34:39PM +0100, Stephan Müller wrote:
> > We would only be able to remove it if all AEAD implementations are
> > converted. But for the conversion time, we do face that issue.
>
> It doesn't
On Mon, Jan 02, 2017 at 01:33:41PM +, Salvatore Benedetto wrote:
> Make sure CRYPTO_ALG_DEAD is not set when preparing for
> alg registration. This fixes qat-dh registration that occurs
> when reloading qat_c62x module.
>
> Signed-off-by: Salvatore Benedetto
> ---
> crypto/kpp.c | 1 +
> 1 f
On Thu, Jan 12, 2017 at 04:34:39PM +0100, Stephan Müller wrote:
>
> We would only be able to remove it if all AEAD implementations are converted.
> But for the conversion time, we do face that issue.
It doesn't matter. Nobody in the kernel uses that. In fact I
wonder whether we should even do i
Am Donnerstag, 12. Januar 2017, 23:27:10 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 04:23:50PM +0100, Stephan Müller wrote:
> > As far as I understand, we have the following AAD copy operations that we
> > discuss:
> >
> > - algif_aead: you suggested to add the AAD copy operat
On Thu, Jan 12, 2017 at 04:23:50PM +0100, Stephan Müller wrote:
>
> As far as I understand, we have the following AAD copy operations that we
> discuss:
>
> - algif_aead: you suggested to add the AAD copy operation here
>
> - AEAD implementations: over time, the AEAD implementations shall receiv
Am Donnerstag, 12. Januar 2017, 22:57:28 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 12:22:09PM +0100, Stephan Müller wrote:
> > When addressing the issue in the algif_aead code, and expect that over
> > time
> > the AEAD implementations will gain the copy operation, eventually
On Thu, Jan 12, 2017 at 11:06:50PM +0800, Herbert Xu wrote:
> On Thu, Jan 12, 2017 at 09:03:18AM -0600, Josh Poimboeuf wrote:
> >
> > For the entry code, could we just replace all calls with CALL_ALIGNED?
> > That might be less intrusive than trying to adjust all the pt_regs
> > accesses.
> >
> >
On Thu, Jan 12, 2017 at 09:03:18AM -0600, Josh Poimboeuf wrote:
> On Wed, Jan 11, 2017 at 11:51:10PM -0800, Andy Lutomirski wrote:
> > On Wed, Jan 11, 2017 at 11:05 PM, Herbert Xu
> > wrote:
> > > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote:
> > >>
> > >> I'm pretty sure we have
On Wed, Jan 11, 2017 at 11:51:10PM -0800, Andy Lutomirski wrote:
> On Wed, Jan 11, 2017 at 11:05 PM, Herbert Xu
> wrote:
> > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote:
> >>
> >> I'm pretty sure we have random asm code that may not maintain a
> >> 16-byte stack alignment when i
From: Wei Yongjun
Fixes the following sparse warning:
drivers/crypto/mediatek/mtk-platform.c:585:27: warning:
symbol 'of_crypto_id' was not declared. Should it be static?
Signed-off-by: Wei Yongjun
---
drivers/crypto/mediatek/mtk-platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
On Thu, Jan 12, 2017 at 09:03:18AM -0600, Josh Poimboeuf wrote:
>
> For the entry code, could we just replace all calls with CALL_ALIGNED?
> That might be less intrusive than trying to adjust all the pt_regs
> accesses.
>
> Then to ensure that nobody ever uses 'call' directly:
>
> '#define cal
On Thu, Jan 12, 2017 at 12:22:09PM +0100, Stephan Müller wrote:
>
> When addressing the issue in the algif_aead code, and expect that over time
> the AEAD implementations will gain the copy operation, eventually we will
> copy
> the AAD twice. Of course, this could be prevented, if the algif_ae
On Thu, Jan 12, 2017 at 08:46:01AM +0100, Ingo Molnar wrote:
>
> * Herbert Xu wrote:
>
> > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote:
> > >
> > > I'm pretty sure we have random asm code that may not maintain a
> > > 16-byte stack alignment when it calls other code (including
On Thu, Jan 12, 2017 at 03:10:25PM +0100, Christian Borntraeger wrote:
> On 01/10/2017 01:56 PM, Christian Borntraeger wrote:
> > On 01/10/2017 01:36 PM, Gonglei (Arei) wrote:
> >> Hi,
> >>
> >>>
> >>> On 12/15/2016 03:03 AM, Gonglei wrote:
> >>> [...]
> +
> +static struct crypto_alg virt
On 01/10/2017 01:56 PM, Christian Borntraeger wrote:
> On 01/10/2017 01:36 PM, Gonglei (Arei) wrote:
>> Hi,
>>
>>>
>>> On 12/15/2016 03:03 AM, Gonglei wrote:
>>> [...]
+
+static struct crypto_alg virtio_crypto_algs[] = { {
+ .cra_name = "cbc(aes)",
+ .cra_driver_name = "virtio
/Add-Support-for-Cavium-Cryptographic-Acceleration-Unit/20170112-192240
config: parisc-allyesconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin
On Wed, Jan 11, 2017 at 10:21:07PM -0800, Andy Lutomirski wrote:
> On Tue, Jan 10, 2017 at 10:01 PM, Andy Lutomirski wrote:
> > On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu
> > wrote:
> >> On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds wrote:
> >>>
> >>> That said, I do think that the "
When working on AES in CCM mode for ARM, my code passed the internal
tcrypt test before I had even bothered to implement the AES-192 and
AES-256 code paths, which is strange because the tcrypt does contain
AES-192 and AES-256 test vectors for CCM.
As it turned out, the define AES_CCM_ENC_TEST_VECT
/Add-Support-for-Cavium-Cryptographic-Acceleration-Unit/20170112-192240
coccinelle warnings: (new ones prefixed by >>)
>> drivers/crypto/cavium/cpt/cptvf_reqmanager.c:312:2-8: WARNING: NULL check
>> before freeing functions like kfree, debugfs_remove,
>> debugfs_remove_r
drivers/crypto/cavium/cpt/cptvf_reqmanager.c:312:2-8: WARNING: NULL check
before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive
or usb_free_urb is not needed. Maybe consider reorganizing relevant code to
avoid passing NULL values.
drivers/crypto/cavium/cpt/cptvf_reqmanage
This patch converts dm-crypt to use bulk requests when invoking skcipher
operations, allowing the crypto drivers to process multiple sectors at once,
while reducing the overhead caused by the small sector size.
The new code detects if multiple sectors from a bio are contigously stored
within a sin
This patch adds bulk request processing to the skcipher interface.
Specifically, it adds a new type of request ('skcipher_bulk_request'), which
allows passing multiple independent messages to the skcipher driver.
The buffers for the message data are passed via just two sg lists (one for src
buffer
This patch adds proper support for the new bulk requests to the SIMD helpers.
Signed-off-by: Ondrej Mosnacek
---
crypto/simd.c | 61 +++
1 file changed, 61 insertions(+)
diff --git a/crypto/simd.c b/crypto/simd.c
index 8820337..2ae5930 100
This patch adds proper support for the new bulk requests to cryptd.
Signed-off-by: Ondrej Mosnacek
---
crypto/cryptd.c | 111
1 file changed, 111 insertions(+)
diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index 0508c48..b7d6e13 100644
-
Hi,
the goal of this patchset is to allow those skcipher API users that need to
process batches of small messages (especially dm-crypt) to do so efficiently.
The first patch introduces a new request type (and corresponding encrypt/decrypt
functions) to the skcipher API. The new API can be used to
This patch implements bulk request handling in the AES-NI crypto drivers.
The major advantage of this is that with bulk requests, the kernel_fpu_*
functions (which are usually quite slow) are now called only once for the whole
request.
Signed-off-by: Ondrej Mosnacek
---
arch/x86/crypto/aesni-int
This patch tweaks skcipher_walk so it can be used with the new bulk requests.
The new skipher_walk can be initialized either from a skcipher_request (in
which case its behavior is equivalent to the old code) or from a
skcipher_bulk_request, in which case the usage is almost identical, the most
sig
Am Donnerstag, 12. Januar 2017, 14:19:36 CET schrieb Herbert Xu:
Hi Herbert,
>
> I think it's too much churn. Let's get the algif_aead code fixed
> up first, and then pursue this later.
To eliminate the extra churn of having all AEAD implementations changed to
invoke copy operation, what abou
-Support-for-Cavium-Cryptographic-Acceleration-Unit/20170112-192240
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
Am Donnerstag, 12. Januar 2017, 14:19:36 CET schrieb Herbert Xu:
Hi Herbert,
> On Tue, Jan 10, 2017 at 02:36:21AM +0100, Stephan Müller wrote:
> > to all driver maintainers: the patches I added are compile tested, but
> > I do not have the hardware to verify the code. May I ask the respective
> >
Hi Stephan,
Thank you for the clarification.
Regards,
-George
On 01/12/2017 04:49 PM, Stephan Müller wrote:
Am Donnerstag, 12. Januar 2017, 16:40:32 CET schrieb George Cherian:
Hi George,
Sure, please do not forget to invoke xts_verify_key.
Should I be using xts_check_key or xts_verify_k
Am Donnerstag, 12. Januar 2017, 16:40:32 CET schrieb George Cherian:
Hi George,
> >
> > Sure, please do not forget to invoke xts_verify_key.
>
> Should I be using xts_check_key or xts_verify_key?
Both are identical except for the input parameter -- the one requires
crypto_skcipher, the other
Hi Stephan,
On 01/11/2017 06:09 PM, Stephan Müller wrote:
Am Mittwoch, 11. Januar 2017, 16:58:17 CET schrieb George Cherian:
Hi George,
I will add a seperate function for xts setkey and make changes as following.
...
+
+struct crypto_alg algs[] = { {
+ .cra_flags = CRYPTO_ALG_TYPE_AB
* Herbert Xu wrote:
> > But if we can't do this with automatic verification, then I'm not sure
> > I want to do it at all. The asm is already more precarious than I'd
> > like, and having a code path that is misaligned is asking for obscure
> > bugs down the road.
>
> I understand the need for
On Thu, Jan 12, 2017 at 08:01:51AM +, Ard Biesheuvel wrote:
>
> [From memory] the arm64 ELF psABI mandates a 16 byte stack alignment
> at function entry, and 8 byte alignment at all other times. This means
> compiled code will typically preserve 16 byte alignment, and
> __aligned(16) on a stac
On Wed, Jan 11, 2017 at 11:51:10PM -0800, Andy Lutomirski wrote:
>
> The problem is that we have nasties like TRACE_IRQS_OFF. Performance
I don't understand. What's the issue with TRACE_IRQS_OFF? It should
be treated as any other function call. That is, enter it with an
aligned stack, and the T
On 12 January 2017 at 06:12, Herbert Xu wrote:
> On Tue, Jan 10, 2017 at 05:30:48PM +, Ard Biesheuvel wrote:
>>
>> Apologies for introducing this breakage. It seemed like an obvious and
>> simple cleanup, so I didn't even bother to mention it in the commit
>> log, but if the kernel does not gu
84 matches
Mail list logo
