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

2017-03-06 Thread Guenter Roeck 

On 03/06/2017 03:20 PM, 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 mips builds fail as follows.

arch/mips/kernel/smp-mt.c: In function ‘vsmp_boot_secondary’:
arch/mips/include/asm/processor.h:384:41: error:
implicit declaration of function ‘task_stack_page’

In file included from
/opt/buildbot/slave/hwmon-testing/build/arch/mips/kernel/pm.c:
arch/mips/include/asm/fpu.h: In function '__own_fpu':
arch/mips/include/asm/processor.h:385:31: error:
invalid application of 'sizeof' to incomplete type 'struct pt_regs'


This one is in an inline function, so I think it'd affect multiple
includes of  even if __own_fpu isn't used, so I think the
following patch which adds the include ptrace.h in fpu.h is more robust
than adding to the individual c files affected:
https://patchwork.linux-mips.org/patch/15386/


Agreed.


Admitedly it could probably have a more specific subject line since
there are more similar errors.


Does that fix all compile problems ? Seems to me that we'll still need

-#include 
+#include 

or did you prepare a patch for this as well ?

Thanks,
Guenter



Cheers
James



arch/mips/netlogic/common/smp.c: In function 'nlm_boot_secondary':
arch/mips/netlogic/common/smp.c:157:2: error:
implicit declaration of function 'task_stack_page'

and more similar errors.

Fixes: f3ac60671954 ("sched/headers: Move task-stack related APIs ...")
Fixes: f780d89a0e82 ("sched/headers: Remove  from ...")
Cc: Ingo Molnar 
Signed-off-by: Guenter Roeck 
---
v3: Catch more build errors

 arch/mips/cavium-octeon/cpu.c  | 3 ++-
 arch/mips/cavium-octeon/crypto/octeon-crypto.c | 1 +
 arch/mips/cavium-octeon/smp.c  | 2 +-
 arch/mips/kernel/pm.c  | 1 +
 arch/mips/kernel/smp-mt.c  | 2 +-
 arch/mips/netlogic/common/smp.c| 1 +
 arch/mips/netlogic/xlp/cop2-ex.c   | 3 ++-
 arch/mips/power/cpu.c  | 1 +
 8 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/mips/cavium-octeon/cpu.c b/arch/mips/cavium-octeon/cpu.c
index a5b427909b5c..b826b7a87c57 100644
--- a/arch/mips/cavium-octeon/cpu.c
+++ b/arch/mips/cavium-octeon/cpu.c
@@ -10,7 +10,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 

 #include 
 #include 
diff --git a/arch/mips/cavium-octeon/crypto/octeon-crypto.c 
b/arch/mips/cavium-octeon/crypto/octeon-crypto.c
index 4d22365844af..cfb4a146cf17 100644
--- a/arch/mips/cavium-octeon/crypto/octeon-crypto.c
+++ b/arch/mips/cavium-octeon/crypto/octeon-crypto.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "octeon-crypto.h"

diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
index 4b94b7fbafa3..d475c0146347 100644
--- a/arch/mips/cavium-octeon/smp.c
+++ b/arch/mips/cavium-octeon/smp.c
@@ -10,8 +10,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
 #include 
 #include 

diff --git a/arch/mips/kernel/pm.c b/arch/mips/kernel/pm.c
index dc814892133c..fab05022ab39 100644
--- a/arch/mips/kernel/pm.c
+++ b/arch/mips/kernel/pm.c
@@ -11,6 +11,7 @@

 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/arch/mips/kernel/smp-mt.c b/arch/mips/kernel/smp-mt.c
index e077ea3e11fb..effc1ed18954 100644
--- a/arch/mips/kernel/smp-mt.c
+++ b/arch/mips/kernel/smp-mt.c
@@ -18,7 +18,7 @@
  * Copyright (C) 2006 Ralf Baechle (r...@linux-mips.org)
  */
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/mips/netlogic/common/smp.c b/arch/mips/netlogic/common/smp.c
index 10d86d54880a..9035558920c1 100644
--- a/arch/mips/netlogic/common/smp.c
+++ b/arch/mips/netlogic/common/smp.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

diff --git a/arch/mips/netlogic/xlp/cop2-ex.c b/arch/mips/netlogic/xlp/cop2-ex.c
index 52bc5de42005..d990b7fc84aa 100644
--- a/arch/mips/netlogic/xlp/cop2-ex.c
+++ b/arch/mips/netlogic/xlp/cop2-ex.c
@@ -13,7 +13,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 

 #include 
 #include 
diff --git a/arch/mips/power/cpu.c b/arch/mips/power/cpu.c
index 2129e67723ff..6e26bf7f 100644
--- a/arch/mips/power/cpu.c
+++ b/arch/mips/power/cpu.c
@@ -7,6 +7,7 @@
  * Author: Hu Hongbing 
  *Wu Zhangjin 
  */
+#include 
 #include 
 #include 
 #include 
--
2.7.4

Re: [RFC PATCH v2 04/32] KVM: SVM: Add SEV feature definitions to KVM

2017-03-06 Thread Borislav Petkov 
On Thu, Mar 02, 2017 at 10:12:48AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> Define a new KVM CPU feature for Secure Encrypted Virtualization (SEV).
> The kernel will check for the presence of this feature to determine if
> it is running with SEV active.
> 
> Define the SEV enable bit for the VMCB control structure. The hypervisor
> will use this bit to enable SEV in the guest.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/svm.h   |1 +
>  arch/x86/include/uapi/asm/kvm_para.h |1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> index 2aca535..fba2a7b 100644
> --- a/arch/x86/include/asm/svm.h
> +++ b/arch/x86/include/asm/svm.h
> @@ -137,6 +137,7 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
>  #define SVM_VM_CR_SVM_DIS_MASK  0x0010ULL
>  
>  #define SVM_NESTED_CTL_NP_ENABLE BIT(0)
> +#define SVM_NESTED_CTL_SEV_ENABLEBIT(1)
>  
>  struct __attribute__ ((__packed__)) vmcb_seg {
>   u16 selector;
> diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
> b/arch/x86/include/uapi/asm/kvm_para.h
> index 1421a65..bc2802f 100644
> --- a/arch/x86/include/uapi/asm/kvm_para.h
> +++ b/arch/x86/include/uapi/asm/kvm_para.h
> @@ -24,6 +24,7 @@
>  #define KVM_FEATURE_STEAL_TIME   5
>  #define KVM_FEATURE_PV_EOI   6
>  #define KVM_FEATURE_PV_UNHALT7
> +#define KVM_FEATURE_SEV  8

This looks like it needs documenting in Documentation/virtual/kvm/cpuid.txt

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

2017-03-06 Thread Bjorn Helgaas 
On Fri, Mar 03, 2017 at 03:15:34PM -0600, Tom Lendacky wrote:
> On 3/3/2017 2:42 PM, Bjorn Helgaas wrote:
> >On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote:
> >>From: Tom Lendacky 
> >>
> >>The use of ioremap will force the setup data to be mapped decrypted even
> >>though setup data is encrypted.  Switch to using memremap which will be
> >>able to perform the proper mapping.
> >
> >How should callers decide whether to use ioremap() or memremap()?
> >
> >memremap() existed before SME and SEV, and this code is used even if
> >SME and SEV aren't supported, so the rationale for this change should
> >not need the decryption argument.
> 
> When SME or SEV is active an ioremap() will remove the encryption bit
> from the pagetable entry when it is mapped.  This allows MMIO, which
> doesn't support SME/SEV, to be performed successfully.  So my take is
> that ioremap() should be used for MMIO and memremap() for pages in RAM.

OK, thanks.  The commit message should say something like "this is
RAM, not MMIO, so we should map it with memremap(), not ioremap()".
That's the part that determines whether the change is correct.

You can mention the encryption part, too, but it's definitely
secondary because the change has to make sense on its own, without
SME/SEV.

The following commits (from https://github.com/codomania/tip/branches)
all do basically the same thing so the changelogs (and summaries)
should all be basically the same:

  cb0d0d1eb0a6 x86: Change early_ioremap to early_memremap for BOOT data
  91acb68b8333 x86/pci: Use memremap when walking setup data
  4f687503e23f x86: Access the setup data through sysfs decrypted
  e90246b8c229 x86: Access the setup data through debugfs decrypted

I would collect them all together and move them to the beginning of
your series, since they don't depend on anything else.

Also, change "x86/pci: " to "x86/PCI" so it matches the previous
convention.

> >>Signed-off-by: Tom Lendacky 

Acked-by: Bjorn Helgaas 

> >>---
> >> arch/x86/pci/common.c |4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
> >>index a4fdfa7..0b06670 100644
> >>--- a/arch/x86/pci/common.c
> >>+++ b/arch/x86/pci/common.c
> >>@@ -691,7 +691,7 @@ int pcibios_add_device(struct pci_dev *dev)
> >>
> >>pa_data = boot_params.hdr.setup_data;
> >>while (pa_data) {
> >>-   data = ioremap(pa_data, sizeof(*rom));
> >>+   data = memremap(pa_data, sizeof(*rom), MEMREMAP_WB);
> >
> >I can't quite connect the dots here.  ioremap() on x86 would do
> >ioremap_nocache().  memremap(MEMREMAP_WB) would do arch_memremap_wb(),
> >which is ioremap_cache().  Is making a cacheable mapping the important
> >difference?
> 
> The memremap(MEMREMAP_WB) will actually check to see if it can perform
> a __va(pa_data) in try_ram_remap() and then fallback to the
> arch_memremap_wb().  So it's actually the __va() vs the ioremap_cache()
> that is the difference.
> 
> Thanks,
> Tom
> 
> >
> >>if (!data)
> >>return -ENOMEM;
> >>
> >>@@ -710,7 +710,7 @@ int pcibios_add_device(struct pci_dev *dev)
> >>}
> >>}
> >>pa_data = data->next;
> >>-   iounmap(data);
> >>+   memunmap(data);
> >>}
> >>set_dma_domain_ops(dev);
> >>set_dev_domain_options(dev);
> >>

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

2017-03-06 Thread James Hogan 
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 mips builds fail as follows.
> 
> arch/mips/kernel/smp-mt.c: In function ‘vsmp_boot_secondary’:
> arch/mips/include/asm/processor.h:384:41: error:
>   implicit declaration of function ‘task_stack_page’
> 
> In file included from
>   /opt/buildbot/slave/hwmon-testing/build/arch/mips/kernel/pm.c:
> arch/mips/include/asm/fpu.h: In function '__own_fpu':
> arch/mips/include/asm/processor.h:385:31: error:
>   invalid application of 'sizeof' to incomplete type 'struct pt_regs'

This one is in an inline function, so I think it'd affect multiple
includes of  even if __own_fpu isn't used, so I think the
following patch which adds the include ptrace.h in fpu.h is more robust
than adding to the individual c files affected:
https://patchwork.linux-mips.org/patch/15386/

Admitedly it could probably have a more specific subject line since
there are more similar errors.

Cheers
James

> 
> arch/mips/netlogic/common/smp.c: In function 'nlm_boot_secondary':
> arch/mips/netlogic/common/smp.c:157:2: error:
>   implicit declaration of function 'task_stack_page'
> 
> and more similar errors.
> 
> Fixes: f3ac60671954 ("sched/headers: Move task-stack related APIs ...")
> Fixes: f780d89a0e82 ("sched/headers: Remove  from ...")
> Cc: Ingo Molnar 
> Signed-off-by: Guenter Roeck 
> ---
> v3: Catch more build errors
> 
>  arch/mips/cavium-octeon/cpu.c  | 3 ++-
>  arch/mips/cavium-octeon/crypto/octeon-crypto.c | 1 +
>  arch/mips/cavium-octeon/smp.c  | 2 +-
>  arch/mips/kernel/pm.c  | 1 +
>  arch/mips/kernel/smp-mt.c  | 2 +-
>  arch/mips/netlogic/common/smp.c| 1 +
>  arch/mips/netlogic/xlp/cop2-ex.c   | 3 ++-
>  arch/mips/power/cpu.c  | 1 +
>  8 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/mips/cavium-octeon/cpu.c b/arch/mips/cavium-octeon/cpu.c
> index a5b427909b5c..b826b7a87c57 100644
> --- a/arch/mips/cavium-octeon/cpu.c
> +++ b/arch/mips/cavium-octeon/cpu.c
> @@ -10,7 +10,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> diff --git a/arch/mips/cavium-octeon/crypto/octeon-crypto.c 
> b/arch/mips/cavium-octeon/crypto/octeon-crypto.c
> index 4d22365844af..cfb4a146cf17 100644
> --- a/arch/mips/cavium-octeon/crypto/octeon-crypto.c
> +++ b/arch/mips/cavium-octeon/crypto/octeon-crypto.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "octeon-crypto.h"
>  
> diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
> index 4b94b7fbafa3..d475c0146347 100644
> --- a/arch/mips/cavium-octeon/smp.c
> +++ b/arch/mips/cavium-octeon/smp.c
> @@ -10,8 +10,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/arch/mips/kernel/pm.c b/arch/mips/kernel/pm.c
> index dc814892133c..fab05022ab39 100644
> --- a/arch/mips/kernel/pm.c
> +++ b/arch/mips/kernel/pm.c
> @@ -11,6 +11,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> diff --git a/arch/mips/kernel/smp-mt.c b/arch/mips/kernel/smp-mt.c
> index e077ea3e11fb..effc1ed18954 100644
> --- a/arch/mips/kernel/smp-mt.c
> +++ b/arch/mips/kernel/smp-mt.c
> @@ -18,7 +18,7 @@
>   * Copyright (C) 2006 Ralf Baechle (r...@linux-mips.org)
>   */
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/mips/netlogic/common/smp.c b/arch/mips/netlogic/common/smp.c
> index 10d86d54880a..9035558920c1 100644
> --- a/arch/mips/netlogic/common/smp.c
> +++ b/arch/mips/netlogic/common/smp.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> diff --git a/arch/mips/netlogic/xlp/cop2-ex.c 
> b/arch/mips/netlogic/xlp/cop2-ex.c
> index 52bc5de42005..d990b7fc84aa 100644
> --- a/arch/mips/netlogic/xlp/cop2-ex.c
> +++ b/arch/mips/netlogic/xlp/cop2-ex.c
> @@ -13,7 +13,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> diff --git a/arch/mips/power/cpu.c b/arch/mips/power/cpu.c
> index 2129e67723ff..6e26bf7f 100644
> --- a/arch/mips/power/cpu.c
> +++ b/arch/mips/power/cpu.c
> @@ -7,6 +7,7 @@
>   * Author: Hu Hongbing 
>   *  Wu Zhangjin 
>   */
> +#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.7.4
> 
> 


signature.asc
Description: Digital signature

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

2017-03-06 Thread Nathan Royce 
OK, I just tried 4.10.0 and the output is looking the same.

I can't say my setup is all that odd. The cryptographic use is only
with the swap partition found in my original email (seen in Herbert's
reply).

My normal build goes as such:
1) git clean -xdf
2) git reset --hard
3) curl 
https://github.com/tobetter/linux/commit/9cdf86bac1db2d74bf98508226e86679581f8f80.patch
| git apply -
   //usb: host: xhci-plat: Get PHYs for xhci's hcds
4) curl 
https://github.com/tobetter/linux/commit/142cf1b68fa0e1710f3623875d5c269cbbc2f005.patch
| git apply -
   //base: platform: name the device already during allocation
5) curl 
https://github.com/tobetter/linux/commit/3772f11d73289ea40825f40ba5c64b5b0e3888ff.patch
| git apply -
   //phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
6) sed -i -e "s/static void exynos5420_usbdrd_phy_calibrate/static int
exynos5420_usbdrd_phy_calibrate/" ./drivers/phy/phy-exynos5-usbdrd.c
7) //duplicate entry in drivers/media/usb/au0828/au0828-cards.c for my
0x400 vid tuner.
8) HOST_EXTRACFLAGS="-O3 -pipe -mfpu=neon-vfpv4 -mfloat-abi=hard
-march=armv7-a -mtune=cortex-a15.cortex-a7" make -j 8 zImage
exynos5422-odroidxu4.dtb modules 2>&1 | tee make.log
9) INSTALL_MOD_PATH=./tmp INSTALL_FW_PATH=./tmp make modules_install
firmware_install 2>&1 | tee makeModFirm.log
10) sudo cp -rv ./tmp/lib/* /usr/lib
11) sudo cp -v ./arch/arm/boot/zImage /boot/zImage-4.10.0
12) sudo cp -v ./arch/arm/boot/dts/exynos5422-odroidxu4.dtb
/boot/exynos5422-odroidxu4-4.10.0.dtb
13) sudo ln -s /boot/zImage-4.10.0 /boot/zImage
14) sudo ln -s /boot/exynos5422-odroidxu4-4.10.0.dtb
/boot/exynos5422-odroidxu4.dtb
15) sudo sync
16) sudo systemctl reboot

I've attached the config I use.

On Mon, Mar 6, 2017 at 11:35 AM, Krzysztof Kozlowski  wrote:
> On Mon, Mar 06, 2017 at 10:18:45AM -0600, Nathan Royce wrote:
>> I tried the patch you submitted, however it also fails for the most part.
>>
>> "For the most part" because "xts" is now found.
>> $ grep xts /proc/crypto
>> name : xts(aes)
>> driver   : xts(ecb-aes-s5p)
>
> Ah, so probably I did not fix the original issue but some other... or
> maybe there are multiple issues.
>
> Could you attach your config and any other essential reproduction steps 
> (unusual settings?).
>
> I saw you tried v4.10.1, could you try just v4.10?
>
> Best regards,
> Krzysztof
>
>>
>> Fail:
>> *
>> [   21.057756] xor: using function: neon (352.000 MB/sec)
>> [   21.064243] Unable to handle kernel NULL pointer dereference at
>> virtual address 0004
>> [   21.070966] pgd = c0004000
>> [   21.073599] [0004] *pgd=
>> [   21.077165] Internal error: Oops: 17 [#1] SMP ARM
>> [   21.081836] Modules linked in: xor aes_arm xor_neon zlib_deflate
>> raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
>> ip_tables x_tables
>> [   21.095239] CPU: 5 PID: 121 Comm: irq/69-1083 Not tainted 
>> 4.10.1-dirty #1
>> [   21.102288] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [   21.108355] task: ee3e3700 task.stack: edcf6000
>> [   21.112821] PC is at post_crypt+0x1b4/0x1c4
>> [   21.116972] LR is at post_crypt+0x1a8/0x1c4
>> [   21.121131] pc : []lr : []psr: 200c0093
>> [   21.121131] sp : edcf7e68  ip : ec59dcf4  fp : 117ce9ac
>> [   21.132576] r10: 244525e3  r9 : c0c0540c  r8 : ec59dc00
>> [   21.137768] r7 :   r6 : 0400  r5 :   r4 : 
>> [   21.144267] r3 : ef49fcde  r2 : 0200  r1 : 0200  r0 : 
>> [   21.150768] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
>> Segment none
>> [   21.157964] Control: 10c5387d  Table: 6618c06a  DAC: 0051
>> [   21.163677] Process irq/69-1083 (pid: 121, stack limit = 0xedcf6218)
>> [   21.170350] Stack: (0xedcf7e68 to 0xedcf8000)
>> [   21.174684] 7e60:   ef49fcdc ec93f200 ef49fcdc
>> ec93f200 ec59dddc 0400
>> [   21.182853] 7e80:   0400  ef49fcdc
>> c01100fc  
>> [   21.190983] 7ea0:    c0110f80 0010
>> 0010 000f 00040a01
>> [   21.199128] 7ec0:  ec59dc00 c0c0540c  
>> 600c0013 0002 
>> [   21.207274] 7ee0: ee889d20 c033608c eea21c90 c05a80d0 eea21ce8
>> eea21c90 000c 00040a01
>> [   21.215418] 7f00: eea21ce8 eea21c90 000c  eea21ce8
>> c05a8290  0001
>> [   21.223564] 7f20: eea2a600 eea8a400 eea8a400 eea2a600 c016ee68
>> c0c0540c  c016ee84
>> [   21.231710] 7f40: edcf6000 eea2a624 eea8a400 c016f198 eea2a640
>>  c016ef7c 00040a01
>> [   21.239868] 7f60:  eeb58280 edcf6000  eea2a640
>> eea2a600 c016f04c eeb582a8
>> [   21.248000] 7f80: ee889d20 c0138710 edcf6000 eea2a640 c0138608
>>   
>> [   21.256145] 7fa0:    c0107a38 
>>   
>> [   21.264291] 7fc0:     
>>   
>> [   21.272428] 7fe0:

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

2017-03-06 Thread Borislav Petkov 
On Mon, Mar 06, 2017 at 01:11:03PM -0500, Brijesh Singh wrote:
> Sending it through stg mail to avoid line wrapping. Please let me know if 
> something
> is still messed up. I have tried applying it and it seems to apply okay.

Yep, thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

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

2017-03-06 Thread Guenter Roeck 
Since commit f3ac60671954 ("sched/headers: Move task-stack related
APIs from  to ") and commit
f780d89a0e82 ("sched/headers: Remove  from
"), various mips builds fail as follows.

arch/mips/kernel/smp-mt.c: In function ‘vsmp_boot_secondary’:
arch/mips/include/asm/processor.h:384:41: error:
implicit declaration of function ‘task_stack_page’

In file included from
/opt/buildbot/slave/hwmon-testing/build/arch/mips/kernel/pm.c:
arch/mips/include/asm/fpu.h: In function '__own_fpu':
arch/mips/include/asm/processor.h:385:31: error:
invalid application of 'sizeof' to incomplete type 'struct pt_regs'

arch/mips/netlogic/common/smp.c: In function 'nlm_boot_secondary':
arch/mips/netlogic/common/smp.c:157:2: error:
implicit declaration of function 'task_stack_page'

and more similar errors.

Fixes: f3ac60671954 ("sched/headers: Move task-stack related APIs ...")
Fixes: f780d89a0e82 ("sched/headers: Remove  from ...")
Cc: Ingo Molnar 
Signed-off-by: Guenter Roeck 
---
v3: Catch more build errors

 arch/mips/cavium-octeon/cpu.c  | 3 ++-
 arch/mips/cavium-octeon/crypto/octeon-crypto.c | 1 +
 arch/mips/cavium-octeon/smp.c  | 2 +-
 arch/mips/kernel/pm.c  | 1 +
 arch/mips/kernel/smp-mt.c  | 2 +-
 arch/mips/netlogic/common/smp.c| 1 +
 arch/mips/netlogic/xlp/cop2-ex.c   | 3 ++-
 arch/mips/power/cpu.c  | 1 +
 8 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/mips/cavium-octeon/cpu.c b/arch/mips/cavium-octeon/cpu.c
index a5b427909b5c..b826b7a87c57 100644
--- a/arch/mips/cavium-octeon/cpu.c
+++ b/arch/mips/cavium-octeon/cpu.c
@@ -10,7 +10,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/mips/cavium-octeon/crypto/octeon-crypto.c 
b/arch/mips/cavium-octeon/crypto/octeon-crypto.c
index 4d22365844af..cfb4a146cf17 100644
--- a/arch/mips/cavium-octeon/crypto/octeon-crypto.c
+++ b/arch/mips/cavium-octeon/crypto/octeon-crypto.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "octeon-crypto.h"
 
diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
index 4b94b7fbafa3..d475c0146347 100644
--- a/arch/mips/cavium-octeon/smp.c
+++ b/arch/mips/cavium-octeon/smp.c
@@ -10,8 +10,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/mips/kernel/pm.c b/arch/mips/kernel/pm.c
index dc814892133c..fab05022ab39 100644
--- a/arch/mips/kernel/pm.c
+++ b/arch/mips/kernel/pm.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/mips/kernel/smp-mt.c b/arch/mips/kernel/smp-mt.c
index e077ea3e11fb..effc1ed18954 100644
--- a/arch/mips/kernel/smp-mt.c
+++ b/arch/mips/kernel/smp-mt.c
@@ -18,7 +18,7 @@
  * Copyright (C) 2006 Ralf Baechle (r...@linux-mips.org)
  */
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/mips/netlogic/common/smp.c b/arch/mips/netlogic/common/smp.c
index 10d86d54880a..9035558920c1 100644
--- a/arch/mips/netlogic/common/smp.c
+++ b/arch/mips/netlogic/common/smp.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/arch/mips/netlogic/xlp/cop2-ex.c b/arch/mips/netlogic/xlp/cop2-ex.c
index 52bc5de42005..d990b7fc84aa 100644
--- a/arch/mips/netlogic/xlp/cop2-ex.c
+++ b/arch/mips/netlogic/xlp/cop2-ex.c
@@ -13,7 +13,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/mips/power/cpu.c b/arch/mips/power/cpu.c
index 2129e67723ff..6e26bf7f 100644
--- a/arch/mips/power/cpu.c
+++ b/arch/mips/power/cpu.c
@@ -7,6 +7,7 @@
  * Author: Hu Hongbing 
  *Wu Zhangjin 
  */
+#include 
 #include 
 #include 
 #include 
-- 
2.7.4

Re: [PATCH 1/1] ARM: dts: NSP: Add crypto (SPU) to dtsi

2017-03-06 Thread Florian Fainelli 
On 02/28/2017 12:31 PM, Florian Fainelli wrote:
> On 02/22/2017 01:22 PM, Steve Lin wrote:
>> Adds crypto hardware (SPU) to Northstar Plus device tree file.
>>
>> Signed-off-by: Steve Lin 
> 
> Applied, thanks!

And dropped, since there is a dependency on "ARM: dts: NSP: Add mailbox
(PDC) to NSP" to be applied first.

Let's wait for the mailbox maintainer to chime in before I apply the
following patches (in that order):

ARM: dts: NSP: Add mailbox (PDC) to NSP
ARM: dts: NSP: Add crypto (SPU) to dtsi

Thanks!
-- 
Florian

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

2017-03-06 Thread Krzysztof Kozlowski 
On Mon, Mar 06, 2017 at 10:18:45AM -0600, Nathan Royce wrote:
> I tried the patch you submitted, however it also fails for the most part.
> 
> "For the most part" because "xts" is now found.
> $ grep xts /proc/crypto
> name : xts(aes)
> driver   : xts(ecb-aes-s5p)

Ah, so probably I did not fix the original issue but some other... or
maybe there are multiple issues.

Could you attach your config and any other essential reproduction steps 
(unusual settings?).

I saw you tried v4.10.1, could you try just v4.10?

Best regards,
Krzysztof

> 
> Fail:
> *
> [   21.057756] xor: using function: neon (352.000 MB/sec)
> [   21.064243] Unable to handle kernel NULL pointer dereference at
> virtual address 0004
> [   21.070966] pgd = c0004000
> [   21.073599] [0004] *pgd=
> [   21.077165] Internal error: Oops: 17 [#1] SMP ARM
> [   21.081836] Modules linked in: xor aes_arm xor_neon zlib_deflate
> raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
> ip_tables x_tables
> [   21.095239] CPU: 5 PID: 121 Comm: irq/69-1083 Not tainted 4.10.1-dirty 
> #1
> [   21.102288] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [   21.108355] task: ee3e3700 task.stack: edcf6000
> [   21.112821] PC is at post_crypt+0x1b4/0x1c4
> [   21.116972] LR is at post_crypt+0x1a8/0x1c4
> [   21.121131] pc : []lr : []psr: 200c0093
> [   21.121131] sp : edcf7e68  ip : ec59dcf4  fp : 117ce9ac
> [   21.132576] r10: 244525e3  r9 : c0c0540c  r8 : ec59dc00
> [   21.137768] r7 :   r6 : 0400  r5 :   r4 : 
> [   21.144267] r3 : ef49fcde  r2 : 0200  r1 : 0200  r0 : 
> [   21.150768] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
> Segment none
> [   21.157964] Control: 10c5387d  Table: 6618c06a  DAC: 0051
> [   21.163677] Process irq/69-1083 (pid: 121, stack limit = 0xedcf6218)
> [   21.170350] Stack: (0xedcf7e68 to 0xedcf8000)
> [   21.174684] 7e60:   ef49fcdc ec93f200 ef49fcdc
> ec93f200 ec59dddc 0400
> [   21.182853] 7e80:   0400  ef49fcdc
> c01100fc  
> [   21.190983] 7ea0:    c0110f80 0010
> 0010 000f 00040a01
> [   21.199128] 7ec0:  ec59dc00 c0c0540c  
> 600c0013 0002 
> [   21.207274] 7ee0: ee889d20 c033608c eea21c90 c05a80d0 eea21ce8
> eea21c90 000c 00040a01
> [   21.215418] 7f00: eea21ce8 eea21c90 000c  eea21ce8
> c05a8290  0001
> [   21.223564] 7f20: eea2a600 eea8a400 eea8a400 eea2a600 c016ee68
> c0c0540c  c016ee84
> [   21.231710] 7f40: edcf6000 eea2a624 eea8a400 c016f198 eea2a640
>  c016ef7c 00040a01
> [   21.239868] 7f60:  eeb58280 edcf6000  eea2a640
> eea2a600 c016f04c eeb582a8
> [   21.248000] 7f80: ee889d20 c0138710 edcf6000 eea2a640 c0138608
>   
> [   21.256145] 7fa0:    c0107a38 
>   
> [   21.264291] 7fc0:     
>   
> [   21.272428] 7fe0:     0013
>   
> [   21.280580] [] (post_crypt) from []
> (decrypt_done+0x4c/0x54)
> [   21.287946] [] (decrypt_done) from []
> (s5p_aes_complete+0x70/0xfc)
> [   21.295845] [] (s5p_aes_complete) from []
> (s5p_aes_interrupt+0x134/0x1a0)
> [   21.304323] [] (s5p_aes_interrupt) from []
> (irq_thread_fn+0x1c/0x54)
> [   21.312378] [] (irq_thread_fn) from []
> (irq_thread+0x14c/0x204)
> [   21.320004] [] (irq_thread) from [] 
> (kthread+0x108/0x138)
> [   21.327109] [] (kthread) from []
> (ret_from_fork+0x14/0x3c)
> [   21.334300] Code: eb0114aa e598c118 e58d001c e1a04000 (e5906004)
> [   21.340363] ---[ end trace e87f375304ecdd42 ]---
> [   21.344961] genirq: exiting task "irq/69-1083" (121) is an
> active IRQ thread (irq 69)
> [   21.870157] irq 69: nobody cared (try booting with the "irqpoll" option)
> [   21.875435] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G  D
> 4.10.1-dirty #1
> [   21.883027] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [   21.889134] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [   21.896826] [] (show_stack) from []
> (dump_stack+0x84/0x98)
> [   21.904015] [] (dump_stack) from []
> (__report_bad_irq+0x2c/0xcc)
> [   21.911716] [] (__report_bad_irq) from []
> (note_interrupt+0x28c/0x2dc)
> [   21.919948] [] (note_interrupt) from []
> (handle_irq_event_percpu+0x5c/0x7c)
> [   21.928614] [] (handle_irq_event_percpu) from
> [] (handle_irq_event+0x38/0x5c)
> [   21.937451] [] (handle_irq_event) from []
> (handle_fasteoi_irq+0xb8/0x190)
> [   21.945944] [] (handle_fasteoi_irq) from []
> (generic_handle_irq+0x24/0x34)
> [   21.954522] [] (generic_handle_irq) from []
> (__handle_domain_irq+0x5c/0xb4)
> [   21.963188] [] (__handle_domain_irq) from []
> (gic_handle_irq+0x38/0x74)
> [   21.971505] [] (gic_handle_irq) from []
> (__irq_svc+0x6c/0x90)

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

2017-03-06 Thread Brijesh Singh 
On 03/04/2017 04:11 AM, Borislav Petkov wrote:
> On Fri, Mar 03, 2017 at 03:01:23PM -0600, Brijesh Singh wrote:
> 
> This looks like a wraparound...
> 
> $ test-apply.sh /tmp/brijesh.singh.delta
> checking file Documentation/admin-guide/kernel-parameters.txt
> Hunk #1 succeeded at 2144 (offset -9 lines).
> checking file Documentation/x86/amd-memory-encryption.txt
> patch:  malformed patch at line 23: DRAM from physical
> 
> Yap.
> 
> Looks like exchange or your mail client decided to do some patch editing
> on its own.
> 
> Please send it to yourself first and try applying.
> 

Sending it through stg mail to avoid line wrapping. Please let me know if 
something
is still messed up. I have tried applying it and it seems to apply okay.

---
 Documentation/admin-guide/kernel-parameters.txt |4 +--
 Documentation/x86/amd-memory-encryption.txt |   33 +--
 arch/x86/include/asm/cpufeature.h   |7 +
 arch/x86/include/asm/cpufeatures.h  |6 +---
 arch/x86/include/asm/disabled-features.h|3 +-
 arch/x86/include/asm/required-features.h|3 +-
 arch/x86/kernel/cpu/amd.c   |   23 
 arch/x86/kernel/cpu/common.c|   23 
 arch/x86/kernel/cpu/scattered.c |1 +
 9 files changed, 50 insertions(+), 53 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 91c40fa..b91e2495 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2153,8 +2153,8 @@
mem_encrypt=on: Activate SME
mem_encrypt=off:Do not activate SME
 
-   Refer to the SME documentation for details on when
-   memory encryption can be activated.
+   Refer to Documentation/x86/amd-memory-encryption.txt
+   for details on when memory encryption can be activated.
 
mem_sleep_default=  [SUSPEND] Default system suspend mode:
s2idle  - Suspend-To-Idle
diff --git a/Documentation/x86/amd-memory-encryption.txt 
b/Documentation/x86/amd-memory-encryption.txt
index 0938e89..0b72ff2 100644
--- a/Documentation/x86/amd-memory-encryption.txt
+++ b/Documentation/x86/amd-memory-encryption.txt
@@ -7,9 +7,9 @@ DRAM.  SME can therefore be used to protect the contents of 
DRAM from physical
 attacks on the system.
 
 A page is encrypted when a page table entry has the encryption bit set (see
-below how to determine the position of the bit).  The encryption bit can be
-specified in the cr3 register, allowing the PGD table to be encrypted. Each
-successive level of page tables can also be encrypted.
+below on how to determine its position).  The encryption bit can be specified
+in the cr3 register, allowing the PGD table to be encrypted. Each successive
+level of page tables can also be encrypted.
 
 Support for SME can be determined through the CPUID instruction. The CPUID
 function 0x801f reports information related to SME:
@@ -17,13 +17,14 @@ function 0x801f reports information related to SME:
0x801f[eax]:
Bit[0] indicates support for SME
0x801f[ebx]:
-   Bit[5:0]  pagetable bit number used to activate memory
- encryption
-   Bit[11:6] reduction in physical address space, in bits, when
- memory encryption is enabled (this only affects system
- physical addresses, not guest physical addresses)
-
-If support for SME is present, MSR 0xc00100010 (SYS_CFG) can be used to
+   Bits[5:0]  pagetable bit number used to activate memory
+  encryption
+   Bits[11:6] reduction in physical address space, in bits, when
+  memory encryption is enabled (this only affects
+  system physical addresses, not guest physical
+  addresses)
+
+If support for SME is present, MSR 0xc00100010 (MSR_K8_SYSCFG) can be used to
 determine if SME is enabled and/or to enable memory encryption:
 
0xc0010010:
@@ -41,7 +42,7 @@ The state of SME in the Linux kernel can be documented as 
follows:
  The CPU supports SME (determined through CPUID instruction).
 
- Enabled:
- Supported and bit 23 of the SYS_CFG MSR is set.
+ Supported and bit 23 of MSR_K8_SYSCFG is set.
 
- Active:
  Supported, Enabled and the Linux kernel is actively applying
@@ -51,7 +52,9 @@ The state of SME in the Linux kernel can be documented as 
follows:
 SME can also be enabled and activated in the BIOS. If SME is enabled and
 activated in the BIOS, then all memory accesses will be encrypted and it will
 not be necessary to activate the Linux memory

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

2017-03-06 Thread Nathan Royce 
I tried the patch you submitted, however it also fails for the most part.

"For the most part" because "xts" is now found.
$ grep xts /proc/crypto
name : xts(aes)
driver   : xts(ecb-aes-s5p)

Fail:
*
[   21.057756] xor: using function: neon (352.000 MB/sec)
[   21.064243] Unable to handle kernel NULL pointer dereference at
virtual address 0004
[   21.070966] pgd = c0004000
[   21.073599] [0004] *pgd=
[   21.077165] Internal error: Oops: 17 [#1] SMP ARM
[   21.081836] Modules linked in: xor aes_arm xor_neon zlib_deflate
raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
ip_tables x_tables
[   21.095239] CPU: 5 PID: 121 Comm: irq/69-1083 Not tainted 4.10.1-dirty #1
[   21.102288] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   21.108355] task: ee3e3700 task.stack: edcf6000
[   21.112821] PC is at post_crypt+0x1b4/0x1c4
[   21.116972] LR is at post_crypt+0x1a8/0x1c4
[   21.121131] pc : []lr : []psr: 200c0093
[   21.121131] sp : edcf7e68  ip : ec59dcf4  fp : 117ce9ac
[   21.132576] r10: 244525e3  r9 : c0c0540c  r8 : ec59dc00
[   21.137768] r7 :   r6 : 0400  r5 :   r4 : 
[   21.144267] r3 : ef49fcde  r2 : 0200  r1 : 0200  r0 : 
[   21.150768] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
Segment none
[   21.157964] Control: 10c5387d  Table: 6618c06a  DAC: 0051
[   21.163677] Process irq/69-1083 (pid: 121, stack limit = 0xedcf6218)
[   21.170350] Stack: (0xedcf7e68 to 0xedcf8000)
[   21.174684] 7e60:   ef49fcdc ec93f200 ef49fcdc
ec93f200 ec59dddc 0400
[   21.182853] 7e80:   0400  ef49fcdc
c01100fc  
[   21.190983] 7ea0:    c0110f80 0010
0010 000f 00040a01
[   21.199128] 7ec0:  ec59dc00 c0c0540c  
600c0013 0002 
[   21.207274] 7ee0: ee889d20 c033608c eea21c90 c05a80d0 eea21ce8
eea21c90 000c 00040a01
[   21.215418] 7f00: eea21ce8 eea21c90 000c  eea21ce8
c05a8290  0001
[   21.223564] 7f20: eea2a600 eea8a400 eea8a400 eea2a600 c016ee68
c0c0540c  c016ee84
[   21.231710] 7f40: edcf6000 eea2a624 eea8a400 c016f198 eea2a640
 c016ef7c 00040a01
[   21.239868] 7f60:  eeb58280 edcf6000  eea2a640
eea2a600 c016f04c eeb582a8
[   21.248000] 7f80: ee889d20 c0138710 edcf6000 eea2a640 c0138608
  
[   21.256145] 7fa0:    c0107a38 
  
[   21.264291] 7fc0:     
  
[   21.272428] 7fe0:     0013
  
[   21.280580] [] (post_crypt) from []
(decrypt_done+0x4c/0x54)
[   21.287946] [] (decrypt_done) from []
(s5p_aes_complete+0x70/0xfc)
[   21.295845] [] (s5p_aes_complete) from []
(s5p_aes_interrupt+0x134/0x1a0)
[   21.304323] [] (s5p_aes_interrupt) from []
(irq_thread_fn+0x1c/0x54)
[   21.312378] [] (irq_thread_fn) from []
(irq_thread+0x14c/0x204)
[   21.320004] [] (irq_thread) from [] (kthread+0x108/0x138)
[   21.327109] [] (kthread) from []
(ret_from_fork+0x14/0x3c)
[   21.334300] Code: eb0114aa e598c118 e58d001c e1a04000 (e5906004)
[   21.340363] ---[ end trace e87f375304ecdd42 ]---
[   21.344961] genirq: exiting task "irq/69-1083" (121) is an
active IRQ thread (irq 69)
[   21.870157] irq 69: nobody cared (try booting with the "irqpoll" option)
[   21.875435] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G  D
4.10.1-dirty #1
[   21.883027] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   21.889134] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[   21.896826] [] (show_stack) from []
(dump_stack+0x84/0x98)
[   21.904015] [] (dump_stack) from []
(__report_bad_irq+0x2c/0xcc)
[   21.911716] [] (__report_bad_irq) from []
(note_interrupt+0x28c/0x2dc)
[   21.919948] [] (note_interrupt) from []
(handle_irq_event_percpu+0x5c/0x7c)
[   21.928614] [] (handle_irq_event_percpu) from
[] (handle_irq_event+0x38/0x5c)
[   21.937451] [] (handle_irq_event) from []
(handle_fasteoi_irq+0xb8/0x190)
[   21.945944] [] (handle_fasteoi_irq) from []
(generic_handle_irq+0x24/0x34)
[   21.954522] [] (generic_handle_irq) from []
(__handle_domain_irq+0x5c/0xb4)
[   21.963188] [] (__handle_domain_irq) from []
(gic_handle_irq+0x38/0x74)
[   21.971505] [] (gic_handle_irq) from []
(__irq_svc+0x6c/0x90)
[   21.978953] Exception stack(0xc0c01e68 to 0xc0c01eb0)
[   21.983975] 1e60:   00200102 c0c5cec0 
 0040 
[   21.992127] 1e80: c0c0 0001 c0c02080 c0c0 
efffc7c0 c0c01f00 c0c01eb8
[   22.000271] 1ea0: c0120b58 c01206d4 600e0113 
[   22.005299] [] (__irq_svc) from []
(__do_softirq+0x90/0x21c)
[   22.012667] [] (__do_softirq) from []
(irq_exit+0xd8/0x140)
[   22.019945] [] (irq_exit) from []
(__handle_domain_irq+0x60/0xb4)
[   22.027743] [] (__handle_domain_irq) from []

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

2017-03-06 Thread Gilad Ben-Yossef 
On Wed, Mar 1, 2017 at 5:38 PM, Milan Broz  wrote:
>
> On 03/01/2017 02:04 PM, Milan Broz wrote:
>> On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote:
>> ...
>>
>>> I can certainly understand if you don't wont to take the patch until
>>> we have results with
>>> dm-crypt itself but the difference between 8 separate invocation of
>>> the engine for 512
>>> bytes of XTS and a single invocation for 4KB are pretty big.
>>
>> Yes, I know it. But the same can be achieved if we just implement
>> 4k sector encryption in dmcrypt. It is incompatible with LUKS1
>> (but next LUKS version will support it) but I think this is not
>> a problem for now.
>>
>> If the underlying device supports atomic write of 4k sectors, then
>> there should not be a problem.
>>
>> This is one of the speed-up I would like to compare with the IV approach,
>> because everyone should benefit from 4k sectors in the end.
>> And no crypto API changes are needed here.
>>
>> (I have an old patch for this, so I will try to revive it.)
>
> If anyone interested, simple experimental patch for larger sector size
> (up to the page size) for dmcrypt is in this branch:
>
> http://git.kernel.org/cgit/linux/kernel/git/mbroz/linux.git/log/?h=dm-crypt-4k-sector
>
> It would be nice to check what performance gain could be provided
> by this simple approach.


I gave it a spin on a x86_64 with 8 CPUs with AES-NI using cryptd and
on Arm  using CryptoCell hardware accelerator.

There was no difference in performance between 512 and 4096 bytes
cluster size on the x86_64 (800 MB loop file system)

There was an improvement in latency of 3.2% between 512 and 4096 bytes
cluster size on the Arm. I expect the performance benefits for this
test for Binoy's patch to be the same.

In both cases the very naive test was a simple dd with block size of
4096 bytes or the raw block device.

I do not know what effect having a bigger cluster size would have on
have on other more complex file system operations.
Is there any specific benchmark worth testing with?


Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH v2 0/2] Propagate fallback bit for cbc and ctr

2017-03-06 Thread Marcelo Cerri 
Hi Herbert,

Any thoughts on this?

On Mon, Feb 27, 2017 at 09:38:24AM -0300, Marcelo Henrique Cerri wrote:
> Hi Hebert,
> 
> For v2:
> 
> - fixed the memory leakage in cbc.
> - included crypto/algapi.h in crypto/cbc.c for crypto_requires_off();
> - ERR_CAST instead PTR_ERR in ctr.
> - Also propagated the fallback bit for rfc3686.
> 
> Marcelo Henrique Cerri (2):
>   crypto: cbc - Propagate NEED_FALLBACK bit
>   crypto: ctr - Propagate NEED_FALLBACK bit
> 
>  crypto/cbc.c | 15 +--
>  crypto/ctr.c | 23 ++-
>  2 files changed, 31 insertions(+), 7 deletions(-)
> 
> -- 
> 2.7.4
> 

-- 
Regards,
Marcelo



signature.asc
Description: PGP signature

[PATCH v6 0/4] Broadcom SBA RAID support

2017-03-06 Thread Anup Patel 
The Broadcom SBA RAID is a stream-based device which provides
RAID5/6 offload.

It requires a SoC specific ring manager (such as Broadcom FlexRM
ring manager) to provide ring-based programming interface. Due to
this, the Broadcom SBA RAID driver (mailbox client) implements
DMA device having one DMA channel using a set of mailbox channels
provided by Broadcom SoC specific ring manager driver (mailbox
controller).

The Broadcom SBA RAID hardware requires PQ disk position instead
of PQ disk coefficient. To address this, we have added raid_gflog
table which will help driver to convert PQ disk coefficient to PQ
disk position.

This patchset is based on Linux-4.11-rc1 and depends on patchset
"[PATCH v5 0/2] Broadcom FlexRM ring manager support"

It is also available at sba-raid-v6 branch of
https://github.com/Broadcom/arm64-linux.git

Changes since v5:
 - Rebased patches for Linux-4.11-rc1

Changes since v4:
 - Removed dependency of bcm-sba-raid driver on kconfig opton
   ASYNC_TX_ENABLE_CHANNEL_SWITCH
 - Select kconfig options ASYNC_TX_DISABLE_XOR_VAL_DMA and
   ASYNC_TX_DISABLE_PQ_VAL_DMA for bcm-sba-raid driver
 - Implemented device_prep_dma_interrupt() using dummy 8-byte
   copy operation so that the dma_async_device_register() can
   set DMA_ASYNC_TX capability for the DMA device provided
   by bcm-sba-raid driver

Changes since v3:
 - Replaced SBA_ENC() with sba_cmd_enc() inline function
 - Use list_first_entry_or_null() wherever possible
 - Remove unwanted brances around loops wherever possible
 - Use lockdep_assert_held() where required

Changes since v2:
 - Droped patch to handle DMA devices having support for fewer
   PQ coefficients in Linux Async Tx
 - Added work-around in bcm-sba-raid driver to handle unsupported
   PQ coefficients using multiple SBA requests

Changes since v1:
 - Droped patch to add mbox_channel_device() API
 - Used GENMASK and BIT macros wherever possible in bcm-sba-raid driver
 - Replaced C_MDATA macros with static inline functions in
   bcm-sba-raid driver
 - Removed sba_alloc_chan_resources() callback in bcm-sba-raid driver
 - Used dev_err() instead of dev_info() wherever applicable
 - Removed call to sba_issue_pending() from sba_tx_submit() in
   bcm-sba-raid driver
 - Implemented SBA request chaning for handling (len > sba->req_size)
   in bcm-sba-raid driver
 - Implemented device_terminate_all() callback in bcm-sba-raid driver

Anup Patel (4):
  lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position
  async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
  dmaengine: Add Broadcom SBA RAID driver
  dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

 .../devicetree/bindings/dma/brcm,iproc-sba.txt |   29 +
 crypto/async_tx/async_pq.c |5 +-
 drivers/dma/Kconfig|   14 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1785 
 include/linux/raid/pq.h|1 +
 lib/raid6/mktables.c   |   20 +
 7 files changed, 1852 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
 create mode 100644 drivers/dma/bcm-sba-raid.c

-- 
2.7.4

[PATCH v6 3/4] dmaengine: Add Broadcom SBA RAID driver

2017-03-06 Thread Anup Patel 
The Broadcom stream buffer accelerator (SBA) provides offloading
capabilities for RAID operations. This SBA offload engine is
accessible via Broadcom SoC specific ring manager.

This patch adds Broadcom SBA RAID driver which provides one
DMA device with RAID capabilities using one or more Broadcom
SoC specific ring manager channels. The SBA RAID driver in its
current shape implements memcpy, xor, and pq operations.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
---
 drivers/dma/Kconfig|   14 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1785 
 3 files changed, 1800 insertions(+)
 create mode 100644 drivers/dma/bcm-sba-raid.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index d01d598..965c7f5 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -99,6 +99,20 @@ config AXI_DMAC
  controller is often used in Analog Device's reference designs for FPGA
  platforms.
 
+config BCM_SBA_RAID
+   tristate "Broadcom SBA RAID engine support"
+   depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
+   select DMA_ENGINE
+   select DMA_ENGINE_RAID
+   select ASYNC_TX_DISABLE_XOR_VAL_DMA
+   select ASYNC_TX_DISABLE_PQ_VAL_DMA
+   default ARCH_BCM_IPROC
+   help
+ Enable support for Broadcom SBA RAID Engine. The SBA RAID
+ engine is available on most of the Broadcom iProc SoCs. It
+ has the capability to offload memcpy, xor and pq computation
+ for raid5/6.
+
 config COH901318
bool "ST-Ericsson COH901318 DMA support"
select DMA_ENGINE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 0b723e9..d12ab29 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
 obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
 obj-$(CONFIG_AT_XDMAC) += at_xdmac.o
 obj-$(CONFIG_AXI_DMAC) += dma-axi-dmac.o
+obj-$(CONFIG_BCM_SBA_RAID) += bcm-sba-raid.o
 obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
 obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
new file mode 100644
index 000..d6b927b
--- /dev/null
+++ b/drivers/dma/bcm-sba-raid.c
@@ -0,0 +1,1785 @@
+/*
+ * Copyright (C) 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Broadcom SBA RAID Driver
+ *
+ * The Broadcom stream buffer accelerator (SBA) provides offloading
+ * capabilities for RAID operations. The SBA offload engine is accessible
+ * via Broadcom SoC specific ring manager. Two or more offload engines
+ * can share same Broadcom SoC specific ring manager due to this Broadcom
+ * SoC specific ring manager driver is implemented as a mailbox controller
+ * driver and offload engine drivers are implemented as mallbox clients.
+ *
+ * Typically, Broadcom SoC specific ring manager will implement larger
+ * number of hardware rings over one or more SBA hardware devices. By
+ * design, the internal buffer size of SBA hardware device is limited
+ * but all offload operations supported by SBA can be broken down into
+ * multiple small size requests and executed parallely on multiple SBA
+ * hardware devices for achieving high through-put.
+ *
+ * The Broadcom SBA RAID driver does not require any register programming
+ * except submitting request to SBA hardware device via mailbox channels.
+ * This driver implements a DMA device with one DMA channel using a set
+ * of mailbox channels provided by Broadcom SoC specific ring manager
+ * driver. To exploit parallelism (as described above), all DMA request
+ * coming to SBA RAID DMA channel are broken down to smaller requests
+ * and submitted to multiple mailbox channels in round-robin fashion.
+ * For having more SBA DMA channels, we can create more SBA device nodes
+ * in Broadcom SoC specific DTS based on number of hardware rings supported
+ * by Broadcom SoC ring manager.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+
+/* SBA command related defines */
+#define SBA_TYPE_SHIFT 48
+#define SBA_TYPE_MASK  GENMASK(1, 0)
+#define SBA_TYPE_A 0x0
+#define SBA_TYPE_B 0x2
+#define SBA_TYPE_C 0x3
+#define SBA_USER_DEF_SHIFT 32
+#define SBA_USER_DEF_MASK  GENMASK(15, 0)
+#define SBA_R_MDATA_SHIFT  24
+#define SBA_R_MDATA_MASK   GENMASK(7, 0)
+#define SBA_C_MDATA_MS_SHIFT

Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex

2017-03-06 Thread Dmitry Vyukov 
On Sun, Mar 5, 2017 at 6:36 PM, Dmitry Vyukov  wrote:
> On Sun, Mar 5, 2017 at 4:08 PM, Dmitry Vyukov  wrote:
>> Hello,
>>
>> I am getting the following deadlock reports while running syzkaller
>> fuzzer on net-next/8d70eeb84ab277377c017af6a21d0a337025dede:
>>
>> ==
>> [ INFO: possible circular locking dependency detected ]
>> 4.10.0+ #5 Not tainted
>> ---
>> syz-executor6/6143 is trying to acquire lock:
>>  (nlk->cb_mutex){+.+.+.}, at: []
>> __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
>>
>> but task is already holding lock:
>>  (crypto_alg_sem){+.}, at: []
>> crypto_user_rcv_msg+0x136/0x4f0 crypto/crypto_user.c:507
>>
>> which lock already depends on the new lock.
>>
>>
>> the existing dependency chain (in reverse order) is:
>>
>> -> #4 (crypto_alg_sem){+.}:
>>validate_chain kernel/locking/lockdep.c:2267 [inline]
>>__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>>lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>>down_read+0x9b/0x150 kernel/locking/rwsem.c:23
>>crypto_alg_lookup+0x23/0x50 crypto/api.c:199
>>crypto_larval_lookup.part.10+0x9a/0x3b0 crypto/api.c:217
>>crypto_larval_lookup crypto/api.c:211 [inline]
>>crypto_alg_mod_lookup+0x77/0x1b0 crypto/api.c:270
>>crypto_alloc_base+0x50/0x1e0 crypto/api.c:416
>>crypto_alloc_cipher include/linux/crypto.h:1407 [inline]
>>tcp_fastopen_reset_cipher+0xc2/0x2e0 net/ipv4/tcp_fastopen.c:48
>>tcp_fastopen_init_key_once+0x114/0x120 net/ipv4/tcp_fastopen.c:29
>>do_tcp_setsockopt.isra.36+0x140a/0x20a0 net/ipv4/tcp.c:2684
>>tcp_setsockopt+0xb0/0xd0 net/ipv4/tcp.c:2733
>>sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2731
>>SYSC_setsockopt net/socket.c:1786 [inline]
>>SyS_setsockopt+0x25c/0x390 net/socket.c:1765
>>entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> -> #3 (sk_lock-AF_INET){+.+.+.}:
>>validate_chain kernel/locking/lockdep.c:2267 [inline]
>>__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>>lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>>lock_sock_nested+0xcb/0x120 net/core/sock.c:2536
>>lock_sock include/net/sock.h:1460 [inline]
>>rds_tcp_listen_stop+0x57/0x140 net/rds/tcp_listen.c:284
>>rds_tcp_kill_sock net/rds/tcp.c:529 [inline]
>>rds_tcp_dev_event+0x383/0xc50 net/rds/tcp.c:568
>>notifier_call_chain+0x1b5/0x2b0 kernel/notifier.c:93
>>__raw_notifier_call_chain kernel/notifier.c:394 [inline]
>>raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
>>call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1646
>>call_netdevice_notifiers net/core/dev.c:1662 [inline]
>>netdev_run_todo+0x3b2/0xa30 net/core/dev.c:7530
>>rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:104
>>default_device_exit_batch+0x504/0x620 net/core/dev.c:8334
>>ops_exit_list.isra.6+0x100/0x150 net/core/net_namespace.c:144
>>cleanup_net+0x551/0xa90 net/core/net_namespace.c:463
>>process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
>>worker_thread+0x223/0x1990 kernel/workqueue.c:2230
>>kthread+0x326/0x3f0 kernel/kthread.c:229
>>ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
>>
>> -> #2 (rtnl_mutex){+.+.+.}:
>>validate_chain kernel/locking/lockdep.c:2267 [inline]
>>__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>>lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>>__mutex_lock_common kernel/locking/mutex.c:756 [inline]
>>__mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
>>mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>>rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
>>tipc_nl_bearer_dump+0x3ef/0x720 net/tipc/bearer.c:774
>>genl_lock_dumpit+0x68/0x90 net/netlink/genetlink.c:479
>>netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127
>>__netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217
>>genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
>>genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
>>netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
>>genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
>>netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
>>netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
>>netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
>>sock_sendmsg_nosec net/socket.c:633 [inline]
>>sock_sendmsg+0xca/0x110 net/socket.c:643
>>sock_write_iter+0x326/0x600 net/socket.c:846
>>call_write_iter include/linux/fs.h:1733 [inline]
>>new_sync_write fs/read_write.c:497 [inline]
>>__vfs_write+0x483/0x740

[PATCH v6 2/4] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()

2017-03-06 Thread Anup Patel 
The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output
of Tx descriptor is to be used by next/dependent Tx descriptor.

The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome()
when calling dma->device_prep_dma_pq() under following conditions:
1. ASYNC_TX_FENCE not set in submit->flags
2. DMA_PREP_FENCE not set in dma_flags
3. src_cnt (= (disks - 2)) is greater than dma_maxpq(dma, dma_flags)

This patch fixes DMA_PREP_FENCE usage in do_async_gen_syndrome() taking
inspiration from do_async_xor() implementation.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 crypto/async_tx/async_pq.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index f83de99..56bd612 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -62,9 +62,6 @@ do_async_gen_syndrome(struct dma_chan *chan,
dma_addr_t dma_dest[2];
int src_off = 0;
 
-   if (submit->flags & ASYNC_TX_FENCE)
-   dma_flags |= DMA_PREP_FENCE;
-
while (src_cnt > 0) {
submit->flags = flags_orig;
pq_src_cnt = min(src_cnt, dma_maxpq(dma, dma_flags));
@@ -83,6 +80,8 @@ do_async_gen_syndrome(struct dma_chan *chan,
if (cb_fn_orig)
dma_flags |= DMA_PREP_INTERRUPT;
}
+   if (submit->flags & ASYNC_TX_FENCE)
+   dma_flags |= DMA_PREP_FENCE;
 
/* Drivers force forward progress in case they can not provide
 * a descriptor
-- 
2.7.4

[PATCH v6 4/4] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

2017-03-06 Thread Anup Patel 
This patch adds the DT bindings document for newly added Broadcom
SBA RAID driver.

Acked-by: Rob Herring 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Anup Patel 
---
 .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt

diff --git a/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt 
b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
new file mode 100644
index 000..092913a
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
@@ -0,0 +1,29 @@
+* Broadcom SBA RAID engine
+
+Required properties:
+- compatible: Should be one of the following
+ "brcm,iproc-sba"
+ "brcm,iproc-sba-v2"
+  The "brcm,iproc-sba" has support for only 6 PQ coefficients
+  The "brcm,iproc-sba-v2" has support for only 30 PQ coefficients
+- mboxes: List of phandle and mailbox channel specifiers
+
+Example:
+
+raid_mbox: mbox@6740 {
+   ...
+   #mbox-cells = <3>;
+   ...
+};
+
+raid0 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 0 0x1 0x>,
+<_mbox 1 0x1 0x>,
+<_mbox 2 0x1 0x>,
+<_mbox 3 0x1 0x>,
+<_mbox 4 0x1 0x>,
+<_mbox 5 0x1 0x>,
+<_mbox 6 0x1 0x>,
+<_mbox 7 0x1 0x>;
+};
-- 
2.7.4

[PATCH v6 1/4] lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position

2017-03-06 Thread Anup Patel 
The raid6_gfexp table represents {2}^n values for 0 <= n < 256. The
Linux async_tx framework pass values from raid6_gfexp as coefficients
for each source to prep_dma_pq() callback of DMA channel with PQ
capability. This creates problem for RAID6 offload engines (such as
Broadcom SBA) which take disk position (i.e. log of {2}) instead of
multiplicative cofficients from raid6_gfexp table.

This patch adds raid6_gflog table having log-of-2 value for any given
x such that 0 <= x < 256. For any given disk coefficient x, the
corresponding disk position is given by raid6_gflog[x]. The RAID6
offload engine driver can use this newly added raid6_gflog table to
get disk position from multiplicative coefficient.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
Reviewed-by: Ray Jui 
---
 include/linux/raid/pq.h |  1 +
 lib/raid6/mktables.c| 20 
 2 files changed, 21 insertions(+)

diff --git a/include/linux/raid/pq.h b/include/linux/raid/pq.h
index 4d57bba..30f9453 100644
--- a/include/linux/raid/pq.h
+++ b/include/linux/raid/pq.h
@@ -142,6 +142,7 @@ int raid6_select_algo(void);
 extern const u8 raid6_gfmul[256][256] __attribute__((aligned(256)));
 extern const u8 raid6_vgfmul[256][32] __attribute__((aligned(256)));
 extern const u8 raid6_gfexp[256]  __attribute__((aligned(256)));
+extern const u8 raid6_gflog[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfinv[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfexi[256]  __attribute__((aligned(256)));
 
diff --git a/lib/raid6/mktables.c b/lib/raid6/mktables.c
index 39787db..e824d08 100644
--- a/lib/raid6/mktables.c
+++ b/lib/raid6/mktables.c
@@ -125,6 +125,26 @@ int main(int argc, char *argv[])
printf("EXPORT_SYMBOL(raid6_gfexp);\n");
printf("#endif\n");
 
+   /* Compute log-of-2 table */
+   printf("\nconst u8 __attribute__((aligned(256)))\n"
+  "raid6_gflog[256] =\n" "{\n");
+   for (i = 0; i < 256; i += 8) {
+   printf("\t");
+   for (j = 0; j < 8; j++) {
+   v = 255;
+   for (k = 0; k < 256; k++)
+   if (exptbl[k] == (i + j)) {
+   v = k;
+   break;
+   }
+   printf("0x%02x,%c", v, (j == 7) ? '\n' : ' ');
+   }
+   }
+   printf("};\n");
+   printf("#ifdef __KERNEL__\n");
+   printf("EXPORT_SYMBOL(raid6_gflog);\n");
+   printf("#endif\n");
+
/* Compute inverse table x^-1 == x^254 */
printf("\nconst u8 __attribute__((aligned(256)))\n"
   "raid6_gfinv[256] =\n" "{\n");
-- 
2.7.4