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 devic
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 might reduce any assumptio
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 ("crypt
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 al
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 LDom
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 Yongjun
Patch applied. T
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 t
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 introd
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 entire
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 a/drivers/crypto/chelsio/chcr_core.c
b/drivers/cry
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
---
drivers/crypto/chelsio/chcr_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
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
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(-)
diff --git a/drivers/crypt
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| 18 ++
drivers/crypto/chels
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.
>
> Please explain why this can'
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 a/crypto/algapi.c b/crypto/algapi.c
index d
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
> > say
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 would
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
Home Page: http://gondor.apana.
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 cop
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 we
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 no
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
> kernel_fpu_begin() and
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
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 not
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
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 a
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 no
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 p
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
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
>
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, th
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
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,
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
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&id=cbf03b255f7c
>
> The order does not matter, though,
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 location
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 m
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 algorithm, make it's higher than software
implementations but lower t
>
> 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: [P
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 that
it can be DMAed at al
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 s
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, so
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 y
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
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 call
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
--
ACK. Whoever takes this patch might want to fixup 3 typos.
On 01/13/2017 07:25 AM, Gonglei wrote:
> Some hardware accelerators (like intel aseni or the s390
aesni
> cpacf functions) have lower priorities than virtio
> crypto, and those drivers are faster th
48 matches
Mail list logo
