warning in crypto_wait_for_test+0x84/0x88

Hello, while booting a latest -net.git kernel on s390x test machine, I've hit this one below, just in case it was not reported yet: [...] [3.317031] qeth 0.0.1000: Outbound TSO not supported on eth0 [3.317123] qeth 0.0.1000: MAC address 02:a1:11:0e:bf:f0 successfully registered on

Re: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256

On 01/11/2017 07:19 PM, Andy Lutomirski wrote: On Wed, Jan 11, 2017 at 1:09 AM, Daniel Borkmann wrote: [...] Ok. Sleeping over this a bit, how about a general rename into "prog_tag" for fdinfo and TCA_BPF_TAG resp. TCA_ACT_BPF_TAG for the netlink attributes, fwiw, it

Re: [PATCH] crypto: arm/aes - avoid reserved 'tt' mnemonic in asm code

On Fri, Jan 13, 2017 at 08:33:26AM +, Ard Biesheuvel wrote: > The ARMv8-M architecture introduces 'tt' and 'ttt' instructions, > which means we can no longer use 'tt' as a register alias on recent > versions of binutils for ARM. So replace the alias with 'ttab'. > > Fixes: 81edb4262975

Re: [PATCH v2] virtio-crypto: adjust priority of algorithm

On Fri, Jan 13, 2017 at 05:34:16PM +0800, Gonglei wrote: > Some hardware accelerators (like intel aesni 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

Re: [PATCH 0/4] n2rng: add support for m5/m7 rng register layout

On Thu, Jan 12, 2017 at 10:52:45AM -0800, Shannon Nelson wrote: > 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

Re: [PATCH -next] crypto: mediatek - make symbol of_crypto_id static

On Thu, Jan 12, 2017 at 03:03:21PM +, Wei Yongjun wrote: > 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

Re: [PATCH] crypto: testmgr - use calculated count for number of test vectors

On Thu, Jan 12, 2017 at 01:40:39PM +, Ard Biesheuvel wrote: > 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

Re: [RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt

On Fri, Jan 13, 2017 at 01:01:56PM +0100, Ondrej Mosnáček wrote: > > As I already mentioned in another thread, there are basically two reasons: > > 1) Milan would like to add authenticated encryption support to > dm-crypt (see [1]) and as part of this change, a new random IV mode > would be

Re: x86-64: Maintain 16-byte stack alignment

On Fri, Jan 13, 2017 at 04:36:48PM +0800, Herbert Xu wrote: > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote: > > > > I think we have some inline functions that do asm volatile ("call > > ..."), and I don't see any credible way of forcing alignment short of > > generating an

[PATCH v1 3/4] crypto:chcr- Check device is allocated before use

Ensure dev is allocated for crypto uld context before using the device for crypto operations. Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chcr_core.c | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git

[PATCH v1 4/4] crypto:chcr-fix itnull.cocci warnings

The first argument to list_for_each_entry cannot be NULL. Generated by: scripts/coccinelle/iterators/itnull.cocci Signed-off-by: Julia Lawall Signed-off-by: Fengguang Wu Signed-off-by: Harsh Jain ---

[PATCH v1 2/4] crypto:chcr- Fix panic on dma_unmap_sg

Save DMA mapped sg list addresses to request context buffer. Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chcr_algo.c | 49 +++- drivers/crypto/chelsio/chcr_crypto.h | 3 +++ 2 files changed, 29 insertions(+), 23 deletions(-)

[PATCH v1 0/4]crypto:chcr- Bug Fixes for 4.10

This patch series is based on Herbert's cryptodev-2.6 tree. It includes several critical bug fixes. Atul Gupta (3): crypto:chcr-Change flow IDs crypto:chcr- Fix panic on dma_unmap_sg crypto:chcr- Check device is allocated before use Julia Lawall (1): crypto:chcr-fix itnull.cocci warnings

[PATCH v1 1/4] crypto:chcr-Change flow IDs

Change assign flowc id to each outgoing request.Firmware use flowc id to schedule each request onto HW. FW reply may lost without this change. Reviewed-by: Hariprasad Shenai Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chcr_algo.c

Re: [RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt

2017-01-13 11:41 GMT+01:00 Herbert Xu : > On Thu, Jan 12, 2017 at 01:59:52PM +0100, Ondrej Mosnacek wrote: >> 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. >

[PATCH] crypto: api - Clear CRYPTO_ALG_DEAD bit before registering an alg

Make sure CRYPTO_ALG_DEAD bit is cleared before proceeding with the algorithm registration. This fixes qat-dh registration when driver is restarted Signed-off-by: Salvatore Benedetto --- crypto/algapi.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 19:25:39 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 12:16:27PM +0100, Stephan Müller wrote: > > > If you're making a single call, what guarantees the ordering? > > > > Technically, io_submit is the syscall that triggers the recvmsg. Are you > >

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 13. Januar 2017, 19:33:24 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 12:30:15PM +0100, Stephan Müller wrote: > > So, the patch set you want to see is: > > > > - remove the AAD copy operation from authenc and not add it to any AEAD > > implementations > > Why

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

On Fri, Jan 13, 2017 at 12:36:56PM +0100, Stephan Müller wrote: > > I thought I understood that you would not want to see it in any > implementation. But, ok, if you want to leave it. If you remove it from authenc then authenc will be broken. -- Email: Herbert Xu

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

On Fri, Jan 13, 2017 at 12:30:15PM +0100, Stephan Müller wrote: > > So, the patch set you want to see is: > > - remove the AAD copy operation from authenc and not add it to any AEAD > implementations Why would you remove it from authenc? > - add the AAD copy operation to algif_aead No just

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 13. Januar 2017, 19:26:23 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 12:19:48PM +0100, Stephan Müller wrote: > > That is correct, but I thought that playing with pointers is always faster > > than doing memcpy. Are you saying that this assumption is not true when

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

On Fri, Jan 13, 2017 at 11:58:24AM +0100, Stephan Müller wrote: > > May I ask how the in-place code path can be invoked by algif_aead or > algif_skcipher? As far as I understand, this code path is only invoked when > the cipher implementation sees that the src and dst SGLs are identical. It's

Re: [RFC PATCH 5/6] crypto: aesni-intel - Add bulk request support

Hi Eric, 2017-01-13 4:19 GMT+01:00 Eric Biggers : > To what extent does the performance benefit of this patchset result from just > the reduced numbers of calls to kernel_fpu_begin() and kernel_fpu_end()? > > If it's most of the benefit, would it make any sense to optimize >

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

On Fri, Jan 13, 2017 at 12:19:48PM +0100, Stephan Müller wrote: > > That is correct, but I thought that playing with pointers is always faster > than doing memcpy. Are you saying that this assumption is not true when we > somehow have the code to try to perform an in-place operation? If you're

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

On Fri, Jan 13, 2017 at 12:16:27PM +0100, Stephan Müller wrote: > > > If you're making a single call, what guarantees the ordering? > > Technically, io_submit is the syscall that triggers the recvmsg. Are you > saying that this syscall does not maintain ordering? At least the man page > does

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 13. Januar 2017, 19:14:06 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 12:12:39PM +0100, Stephan Müller wrote: > > Adding such code should IMHO not be impaired by pointing to the AAD held > > in > > the src SGL by the dst SGL as offered with the older patch mentioned

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 19:12:59 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 12:10:02PM +0100, Stephan Müller wrote: > > > Well if ordering is not guaranteed that I don't see how your code > > > can work either. Or am I missing something? > > > > The patch simply stores

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

On Fri, Jan 13, 2017 at 12:12:39PM +0100, Stephan Müller wrote: > > Adding such code should IMHO not be impaired by pointing to the AAD held in > the src SGL by the dst SGL as offered with the older patch mentioned before. The point is you're turning what could otherwise be a linear SGL into a

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

On Fri, Jan 13, 2017 at 12:10:02PM +0100, Stephan Müller wrote: > > > Well if ordering is not guaranteed that I don't see how your code > > can work either. Or am I missing something? > > The patch simply stores all data it gets from sendmsg in the src SGL. In > addition it maintains an offset

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 13. Januar 2017, 19:04:17 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 11:58:24AM +0100, Stephan Müller wrote: > > May I ask how the in-place code path can be invoked by algif_aead or > > algif_skcipher? As far as I understand, this code path is only invoked > > when

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 19:03:35 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 11:49:05AM +0100, Stephan Müller wrote: > > According to the man page of lio_listio(3) the provided AIO operations are > > executed in an unspecified order. I would infer from that statement that

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

On Fri, Jan 13, 2017 at 11:49:05AM +0100, Stephan Müller wrote: > > According to the man page of lio_listio(3) the provided AIO operations are > executed in an unspecified order. I would infer from that statement that even > if an order of write / read / write / read is defined by the caller,

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 13. Januar 2017, 18:23:39 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 05:37:33PM +0100, Stephan Müller wrote: > > I would not understand that statement. > > > > With the patch mentioned above that I provided some weeks ago, we have the > > following scenario for an

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 18:21:45 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 05:19:57PM +0100, Stephan Müller wrote: > > > I don't understand, what's wrong with: > > > > > > sendmsg(fd, ...) > > > aio_read(iocb1) > > > sendmsg(fd, ...) > > > aio_read(iocb2) > > > > Sure,

Re: [RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt

On Thu, Jan 12, 2017 at 01:59:52PM +0100, Ondrej Mosnacek wrote: > > 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. Please explain why this can't be done with the existing framework using

Re: [PATCH v2 0/7] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11

On Thu, Jan 12, 2017 at 04:48:08PM +, Ard Biesheuvel wrote: > > Actually, patch #6 was the huge one not #7, and I don't see it in your tree > yet. > > https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/commit/?h=crypto-arm-v4.11=cbf03b255f7c > > The order does not matter, though,

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

On Thu, Jan 12, 2017 at 05:37:33PM +0100, Stephan Müller wrote: > > I would not understand that statement. > > With the patch mentioned above that I provided some weeks ago, we have the > following scenario for an encryption (in case of decryption, it is almost > identical, just the tag

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

On Thu, Jan 12, 2017 at 05:19:57PM +0100, Stephan Müller wrote: > > > I don't understand, what's wrong with: > > > > sendmsg(fd, ...) > > aio_read(iocb1) > > sendmsg(fd, ...) > > aio_read(iocb2) > > Sure, that works. But here you limit yourself to one IOCB per aio_read. But > aio_read supports

RE: [PATCH] virtio-crypto: adjust priority of algorithm

> > From: Christian Borntraeger [mailto:borntrae...@de.ibm.com] > Sent: Friday, January 13, 2017 4:28 PM > To: Gonglei (Arei); virtualizat...@lists.linux-foundation.org; > linux-crypto@vger.kernel.org; linux-ker...@vger.kernel.org > Cc: m...@redhat.com; herb...@gondor.apana.org.au > Subject: Re:

Re: [PATCH] crypto: testmgr - don't DMA map IV from stack in test_skcipher()

On Fri, Jan 13, 2017 at 08:59:16AM +0200, Horia Geantă wrote: > Fix the "DMA-API: device driver maps memory from stack" warning > generated when crypto accelerators map the IV. > > Signed-off-by: Horia Geantă Hmm, the IV comes in as a pointer. So you should not assume

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 11:07:09PM -0600, Josh Poimboeuf wrote: > > Disabling frame pointers didn't seem to help, but I finally got it to > misalign with a different test case. I think it had been aligning the > array, so instead I made it push a register. Right. If you start manipulating the

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 08:37:18PM -0800, Linus Torvalds wrote: > > So then the compiler actually needs to start adding useless instructions > just to keep the stack 16-byte aligned. Which it does. Of course most of the time no extra instructions are required because there are stack variables,

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote: > > What I mean is: what guarantees that the stack is properly aligned for > the subroutine call? gcc promises to set up a stack frame, but does > it promise that rsp will be properly aligned to call a C function? Yes, as long as

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 01:40:54PM -0800, Linus Torvalds wrote: > > The 8-byte alignment mainly makes sense when the basic call sequence > just adds 8 bytes, and you have functions without frames (that still > call other functions). The question is does it really make sense to save those 8 bytes

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote: > > I think we have some inline functions that do asm volatile ("call > ..."), and I don't see any credible way of forcing alignment short of > generating an entirely new stack frame and aligning that. Ick. This A straight asm

[PATCH] crypto: arm/aes - avoid reserved 'tt' mnemonic in asm code

The ARMv8-M architecture introduces 'tt' and 'ttt' instructions, which means we can no longer use 'tt' as a register alias on recent versions of binutils for ARM. So replace the alias with 'ttab'. Fixes: 81edb4262975 ("crypto: arm/aes - replace scalar AES cipher") Signed-off-by: Ard Biesheuvel