Re: [PATCH] crypto: x86/twofish-3way - Fix %rbp usage

* Ingo Molnar <mi...@kernel.org> wrote: > > * Eric Biggers <ebigge...@gmail.com> wrote: > > > There may be a small overhead caused by replacing 'xchg REG, REG' with > > the needed sequence 'mov MEM, REG; mov REG, MEM; mov REG, REG' once per > > round.

Re: [PATCH] crypto: x86/twofish-3way - Fix %rbp usage

* Eric Biggers wrote: > There may be a small overhead caused by replacing 'xchg REG, REG' with > the needed sequence 'mov MEM, REG; mov REG, MEM; mov REG, REG' once per > round. But, counterintuitively, when I tested "ctr-twofish-3way" on a > Haswell processor, the new

Re: [PATCH 00/12] x86/crypto: Fix RBP usage in several crypto .S files

* Eric Biggers <ebigge...@gmail.com> wrote: > On Fri, Sep 15, 2017 at 07:34:31AM +0200, Ingo Molnar wrote: > > > > * Eric Biggers <ebigge...@gmail.com> wrote: > > > > > Hi Josh, > > > > > > On Wed, Sep 13, 2017 at 05:33:03PM -050

Re: [PATCH 00/12] x86/crypto: Fix RBP usage in several crypto .S files

* Josh Poimboeuf wrote: > > So if this observation of mine is true we could go back to the old code for > > the > > hotpath, but use RDI for TBL and not reload it in the hotpath. > > Thanks for the excellent breakdown. > > When I looked at the patch again, I came to the

Re: [PATCH 00/12] x86/crypto: Fix RBP usage in several crypto .S files

* Eric Biggers wrote: > Hi Josh, > > On Wed, Sep 13, 2017 at 05:33:03PM -0500, Josh Poimboeuf wrote: > > And here's v2 of the sha512-avx2 patch. It should hopefully gain back > > most of the performance lost by v1. > > > > From: Josh Poimboeuf > >

Re: [PATCH 00/12] x86/crypto: Fix RBP usage in several crypto .S files

* Ingo Molnar <mi...@kernel.org> wrote: > 1) > > Note how R12 is used immediately, right in the next instruction: > > vpaddq (TBL), Y_0, XFER > > I.e. the RBP fixes lengthen the program order data dependencies - that's a > new > constraint and a fe

Re: [PATCH 00/12] x86/crypto: Fix RBP usage in several crypto .S files

* Josh Poimboeuf wrote: > I'm still looking at the other one (sha512-avx2), but so far I haven't > found a way to speed it back up. Here's a couple of very quick observations with possible optimizations: AFAICS the main effect of the RBP fixes is the introduction of a

Re: [PATCH 00/12] x86/crypto: Fix RBP usage in several crypto .S files

* Eric Biggers <ebigge...@gmail.com> wrote: > On Thu, Sep 07, 2017 at 09:15:34AM +0200, Ingo Molnar wrote: > > > > * Eric Biggers <ebigge...@gmail.com> wrote: > > > > > Thanks for fixing these! I don't have time to review these in detail, &

Re: [PATCH 00/12] x86/crypto: Fix RBP usage in several crypto .S files

* Eric Biggers wrote: > Thanks for fixing these! I don't have time to review these in detail, but I > ran > the crypto self-tests on the affected algorithms, and they all pass. I also > benchmarked them before and after; the only noticable performance difference > was >

Re: [PATCH v3] MIPS: Fix build breakage caused by header file changes

* James Hogan <james.ho...@imgtec.com> wrote: > Hi Ingo, > > On Tue, Mar 07, 2017 at 08:38:05AM +0100, Ingo Molnar wrote: > > Just a quick question: is your MIPS build fix going to be merged and sent > > to > > Linus? I can apply it too, and send

Re: [PATCH v3] MIPS: Fix build breakage caused by header file changes

* James Hogan wrote: > Hi Guenter, > > On Mon, Mar 06, 2017 at 11:13:55AM -0800, Guenter Roeck wrote: > > Since commit f3ac60671954 ("sched/headers: Move task-stack related > > APIs from to ") and commit > > f780d89a0e82 ("sched/headers: Remove from > > "), various

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

* 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.

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

* 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, in some > > cases, calling C code). > > >

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

* Andy Lutomirski wrote: > I find it rather annoying that gcc before 4.8 malfunctions when it > sees __aligned__(16) on x86_64 kernels. Sigh. Ran into this when writing silly FPU in-kernel testcases a couple of months ago... Thanks, Ingo -- To unsubscribe from

Re: [patch] crypto: sha256-mb - cleanup a || vs | typo

* Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Fri, Jul 01, 2016 at 09:55:59AM +0200, Ingo Molnar wrote: > > > > Plus: > > > > > > >   /* Compute how many bytes to copy from user buffer into > > > > >    

Re: [patch] crypto: sha256-mb - cleanup a || vs | typo

* Tim Chen wrote: > On Wed, 2016-06-29 at 10:05 -0700, H. Peter Anvin wrote: > > On 06/29/16 07:42, Dan Carpenter wrote: > > > > > > > > > > > > > > > > > and | behave basically the same here but || is intended.  It causes a > > > static checker warning to mix up

Re: SHA1-MB algorithm broken on latest kernel

* Herbert Xu wrote: > On Thu, May 12, 2016 at 04:31:06PM -0700, Megha Dey wrote: > > Hi, > > > > When booting latest kernel with the CONFIG_CRYPTO_SHA1_MB enabled, I > > observe a panic. > > > > After having a quick look, on reverting the following patches, I am

Re: [PATCH] crypto x86/camellia_aesni_avx: Fix CPU feature checks

* Ben Hutchings wrote: > We need to explicitly check the AVX and AES CPU features, as we can't > infer them from the related XSAVE feature flags. For example, the > Core i3 2310M passes the XSAVE feature test but does not implement > AES-NI. > > Reported-and-tested-by:

Re: tip: origin tree boot crash

* Herbert Xu herb...@gondor.apana.org.au wrote: On Mon, Mar 01, 2010 at 03:55:19PM +0100, Steffen Klassert wrote: On Mon, Mar 01, 2010 at 08:50:24AM +0100, Ingo Molnar wrote: * Herbert Xu herb...@gondor.apana.org.au wrote: crypto: pcrypt - Add pcrypt crypto

Re: [PATCH 1/2] x86, crypto, Generate .byte code for some new instructions via gas macro

* H. Peter Anvin h...@zytor.com wrote: On 11/05/2009 06:23 AM, Herbert Xu wrote: On Thu, Nov 05, 2009 at 02:44:15PM +0800, Huang Ying wrote: It will take some time for binutils (gas) to support some newly added instructions, such as SSE4.1 instructions or the AES-NI instructions found

Re: [PATCH -v4] crypto: Add PCLMULQDQ accelerated GHASH implementation

* Huang Ying ying.hu...@intel.com wrote: On Mon, 2009-11-02 at 22:32 +0800, Ingo Molnar wrote: * Herbert Xu herb...@gondor.apana.org.au wrote: On Mon, Nov 02, 2009 at 08:50:39AM +0100, Ingo Molnar wrote: A cleanup request: mind creating two macros for this PSHUFB MMX/SSE

Re: [PATCH -v4] crypto: Add PCLMULQDQ accelerated GHASH implementation

* Herbert Xu herb...@gondor.apana.org.au wrote: On Mon, Nov 02, 2009 at 08:50:39AM +0100, Ingo Molnar wrote: A cleanup request: mind creating two macros for this PSHUFB MMX/SSE instruction in arch/x86/include/asm/i387.h, instead of open-coding the .byte sequences in ~6 places? I

Re: [PATCH -v4] crypto: Add PCLMULQDQ accelerated GHASH implementation

* Herbert Xu herb...@gondor.apana.org.au wrote: On Mon, Nov 02, 2009 at 03:32:58PM +0100, Ingo Molnar wrote: Please use the standard construct and put an #ifndef __ASSEMBLY__ around it. You mean like this? diff --git a/arch/x86/include/asm/i387.h b/arch/x86/include/asm/i387.h

Re: [PATCH -v4] crypto: Add PCLMULQDQ accelerated GHASH implementation

* Herbert Xu herb...@gondor.apana.org.au wrote: - pshufb BSWAP, DATA + # pshufb BSWAP, DATA + .byte 0x66, 0x0f, 0x38, 0x00, 0xc5 A cleanup request: mind creating two macros for this PSHUFB MMX/SSE instruction in arch/x86/include/asm/i387.h, instead of open-coding the .byte

Re: [RFC 6/7] x86: Move kernel_fpu_using to asm/i387.h

* Huang Ying ying.hu...@intel.com wrote: This is used by AES-NI accelerated AES implementation and PCLMULQDQ accelerated GHASH implementation. Signed-off-by: Huang Ying ying.hu...@intel.com --- arch/x86/crypto/aesni-intel_glue.c |7 --- arch/x86/include/asm/i387.h|

Re: [patch 5/5] Apply the PG_sensitive flag to the CryptoAPI subsystem

* Larry H. resea...@subreption.com wrote: This patch deploys the use of the PG_sensitive page allocator flag within the CryptoAPI subsystem, in all relevant locations where algorithm and key contexts are allocated. Some calls to memset for zeroing the buffers have been removed to avoid

Re: enable padlock on x86_64

* Sebastian Andrzej Siewior sebast...@breakpoint.cc wrote: To enable the padlock unit, two msr bits have to flipped. This is allready done in the 32bit path and is missing in the other. Instead of copy paste the code, I merged the 64bit part into the 32bit part. The things that changed

[PATCH] crypto: fix error flow of crypto/testmgr.c:test_comp()

Noticed the bug below while running our -Werror x86 randconfig build tests against tip/master. Please double check my control flow analysis. Ingo -- From e5c3b90a18b73d593bba2a3f927a79469b6218d7 Mon Sep 17 00:00:00 2001 From: Ingo Molnar [EMAIL PROTECTED] Date: Tue, 25 Nov

[warnings] 37 warning fixes in networking related files

* David Miller [EMAIL PROTECTED] wrote: From: Ingo Molnar [EMAIL PROTECTED] Date: Tue, 25 Nov 2008 18:14:38 +0100 btw, on a related note, there's a couple of networking related warning fixes/annotations i've got queued up. I see these now, but they would get properly logged

Re: [PATCH] crypto: fix error flow of crypto/testmgr.c:test_comp()

* David Miller [EMAIL PROTECTED] wrote: fix warning in drivers/net/sky2.c fix warning in net/sunrpc/svcauth_unix.c fix warning in security/selinux/netnode.c fix warning in net/packet/af_packet.c fix warning in net/rfkill/rfkill.c Not applied. Changing this from