* Re: [PATCH v3] MIPS: Fix build breakage caused by header file changes
From: Ingo Molnar @ 2017-03-07 10:34 UTC (permalink / raw)
To: James Hogan
Cc: Guenter Roeck, Ralf Baechle, Herbert Xu, linux-mips, linux-kernel,
linux-crypto, Linus Torvalds
In-Reply-To: <20170307093850.GD996@jhogan-linux.le.imgtec.org>
* James Hogan <james.hogan@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 it to Linus later today, together with a few
> > other sched.h header related build fixes.
>
> One for Ralf...
Ralf, what's your preference?
> > Assuming it's all properly tested - my limited MIPS defconfig builds worked fine -
> > but MIPS has a lot of build variations.
>
> If you have a branch with other generic fixes I'm happy to push it to
> our MIPS buildbot too to double check.
So I have not applied your patch yet (can do it with ack from Ralf), but all the
other fixes that are pending can be found in:
git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/urgent
It's these commits:
bb35e4515411 drivers/char/nwbutton: Fix build breakage caused by include file reshuffling
80aa1a54f054 h8300: Fix build breakage caused by header file changes
1fbdbcea8005 avr32: Fix build error caused by include file reshuffling
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v3] MIPS: Fix build breakage caused by header file changes
From: James Hogan @ 2017-03-07 10:31 UTC (permalink / raw)
To: Guenter Roeck
Cc: Ralf Baechle, Herbert Xu, linux-mips, linux-kernel, linux-crypto,
Ingo Molnar
In-Reply-To: <20170307093339.GC996@jhogan-linux.le.imgtec.org>
[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]
Hi Guenter,
On Tue, Mar 07, 2017 at 09:33:40AM +0000, James Hogan wrote:
> On Mon, Mar 06, 2017 at 07:30:05PM -0800, Guenter Roeck wrote:
> > On 03/06/2017 03:20 PM, James Hogan wrote:
> > > On Mon, Mar 06, 2017 at 11:13:55AM -0800, Guenter Roeck wrote:
> > >> Since commit f3ac60671954 ("sched/headers: Move task-stack related
> > >> APIs from <linux/sched.h> to <linux/sched/task_stack.h>") and commit
> > >> f780d89a0e82 ("sched/headers: Remove <asm/ptrace.h> from
> > >> <linux/sched.h>"), 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 <asm/fpu.h> 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 <linux/sched.h>
> > +#include <linux/sched/task_stack.h>
> >
> > or did you prepare a patch for this as well ?
>
> It fixed the config I was using at the time. I didn't do a full build
> test of all configs at the time so didn't fix the above.
More specifically your changes to the following files:
arch/mips/kernel/pm.c
arch/mips/power/cpu.c
Don't appear to be necessary with my patch above, but the rest look good
to me. With those changes removed:
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Build testing of that in progress...
Thanks
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3] MIPS: Fix build breakage caused by header file changes
From: James Hogan @ 2017-03-07 9:38 UTC (permalink / raw)
To: Ingo Molnar
Cc: Guenter Roeck, Ralf Baechle, Herbert Xu, linux-mips, linux-kernel,
linux-crypto, Linus Torvalds
In-Reply-To: <20170307073805.GB15693@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
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 it to Linus later today, together with a few
> other sched.h header related build fixes.
One for Ralf...
> Assuming it's all properly tested - my limited MIPS defconfig builds worked fine -
> but MIPS has a lot of build variations.
If you have a branch with other generic fixes I'm happy to push it to
our MIPS buildbot too to double check.
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3] MIPS: Fix build breakage caused by header file changes
From: James Hogan @ 2017-03-07 9:33 UTC (permalink / raw)
To: Guenter Roeck
Cc: Ralf Baechle, Herbert Xu, linux-mips, linux-kernel, linux-crypto,
Ingo Molnar
In-Reply-To: <146eef7a-44dd-48ff-3f09-0b342d844bd6@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]
On Mon, Mar 06, 2017 at 07:30:05PM -0800, Guenter Roeck wrote:
> On 03/06/2017 03:20 PM, James Hogan wrote:
> > On Mon, Mar 06, 2017 at 11:13:55AM -0800, Guenter Roeck wrote:
> >> Since commit f3ac60671954 ("sched/headers: Move task-stack related
> >> APIs from <linux/sched.h> to <linux/sched/task_stack.h>") and commit
> >> f780d89a0e82 ("sched/headers: Remove <asm/ptrace.h> from
> >> <linux/sched.h>"), 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 <asm/fpu.h> 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 <linux/sched.h>
> +#include <linux/sched/task_stack.h>
>
> or did you prepare a patch for this as well ?
It fixed the config I was using at the time. I didn't do a full build
test of all configs at the time so didn't fix the above.
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Mutual Cooperation! Thank you.
From: Mr Obama Basolle @ 2017-03-07 9:26 UTC (permalink / raw)
--
Dear Friend,
I know that this message will come to you as a surprise. I am the
Auditing and Accounting section manager with African Development Bank,
Ouagadougou Burkina faso. I Hope that you will not expose or betray
this trust and confident that I am about to repose on you for the
mutual benefit of our both families.
I need your urgent assistance in transferring the sum of($39.5)million
to your account within 10 or 14 banking days. This money has been
dormant for years in our Bank without claim.I want the bank to release
the money to you as the nearest person to our deceased customer late
George small. who died along with his supposed next of kin in an air
crash since 31st October 1999.
I don't want the money to go into government treasury as an abandoned
fund. So this is the reason why I am contacting you so that the bank
can release the money to you as the next of kin to the deceased
customer. Please I would like you to keep this proposal as atop secret
and delete it if you are not interested.
Upon receipt of your reply, I will give you full details on how the
business will be executed and also note that you will have 40% of the
above mentioned sum if you agree to handle this business with me.
I am expecting your urgent response as soon as you receive my message.
Best Regard,
Auditor Mr Obama Basolle.
^ permalink raw reply
* Re: [PATCH v3] MIPS: Fix build breakage caused by header file changes
From: Ingo Molnar @ 2017-03-07 7:38 UTC (permalink / raw)
To: James Hogan
Cc: Guenter Roeck, Ralf Baechle, Herbert Xu, linux-mips, linux-kernel,
linux-crypto, Linus Torvalds
In-Reply-To: <20170306232019.GG2878@jhogan-linux.le.imgtec.org>
* James Hogan <james.hogan@imgtec.com> 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 <linux/sched.h> to <linux/sched/task_stack.h>") and commit
> > f780d89a0e82 ("sched/headers: Remove <asm/ptrace.h> from
> > <linux/sched.h>"), 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 <asm/fpu.h> 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.
Just a quick question: is your MIPS build fix going to be merged and sent to
Linus? I can apply it too, and send it to Linus later today, together with a few
other sched.h header related build fixes.
Assuming it's all properly tested - my limited MIPS defconfig builds worked fine -
but MIPS has a lot of build variations.
Either way is fine to me.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v3] MIPS: Fix build breakage caused by header file changes
From: Guenter Roeck @ 2017-03-07 3:30 UTC (permalink / raw)
To: James Hogan
Cc: Ralf Baechle, Herbert Xu, linux-mips, linux-kernel, linux-crypto,
Ingo Molnar
In-Reply-To: <20170306232019.GG2878@jhogan-linux.le.imgtec.org>
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 <linux/sched.h> to <linux/sched/task_stack.h>") and commit
>> f780d89a0e82 ("sched/headers: Remove <asm/ptrace.h> from
>> <linux/sched.h>"), 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 <asm/fpu.h> 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 <linux/sched.h>
+#include <linux/sched/task_stack.h>
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 <asm/ptrace.h> from ...")
>> Cc: Ingo Molnar <mingo@kernel.org>
>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>> ---
>> 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 <linux/irqflags.h>
>> #include <linux/notifier.h>
>> #include <linux/prefetch.h>
>> -#include <linux/sched.h>
>> +#include <linux/ptrace.h>
>> +#include <linux/sched/task_stack.h>
>>
>> #include <asm/cop2.h>
>> #include <asm/current.h>
>> 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 <asm/cop2.h>
>> #include <linux/export.h>
>> #include <linux/interrupt.h>
>> +#include <linux/sched/task_stack.h>
>>
>> #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 <linux/smp.h>
>> #include <linux/interrupt.h>
>> #include <linux/kernel_stat.h>
>> -#include <linux/sched.h>
>> #include <linux/sched/hotplug.h>
>> +#include <linux/sched/task_stack.h>
>> #include <linux/init.h>
>> #include <linux/export.h>
>>
>> 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 <linux/cpu_pm.h>
>> #include <linux/init.h>
>> +#include <linux/ptrace.h>
>>
>> #include <asm/dsp.h>
>> #include <asm/fpu.h>
>> 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 (ralf@linux-mips.org)
>> */
>> #include <linux/kernel.h>
>> -#include <linux/sched.h>
>> +#include <linux/sched/task_stack.h>
>> #include <linux/cpumask.h>
>> #include <linux/interrupt.h>
>> #include <linux/irqchip/mips-gic.h>
>> 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 <linux/init.h>
>> #include <linux/smp.h>
>> #include <linux/irq.h>
>> +#include <linux/sched/task_stack.h>
>>
>> #include <asm/mmu_context.h>
>>
>> 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 <linux/irqflags.h>
>> #include <linux/notifier.h>
>> #include <linux/prefetch.h>
>> -#include <linux/sched.h>
>> +#include <linux/ptrace.h>
>> +#include <linux/sched/task_stack.h>
>>
>> #include <asm/cop2.h>
>> #include <asm/current.h>
>> diff --git a/arch/mips/power/cpu.c b/arch/mips/power/cpu.c
>> index 2129e67723ff..6ecccc26bf7f 100644
>> --- a/arch/mips/power/cpu.c
>> +++ b/arch/mips/power/cpu.c
>> @@ -7,6 +7,7 @@
>> * Author: Hu Hongbing <huhb@lemote.com>
>> * Wu Zhangjin <wuzhangjin@gmail.com>
>> */
>> +#include <linux/ptrace.h>
>> #include <asm/sections.h>
>> #include <asm/fpu.h>
>> #include <asm/dsp.h>
>> --
>> 2.7.4
>>
>>
^ permalink raw reply
* Re: [RFC PATCH v2 04/32] KVM: SVM: Add SEV feature definitions to KVM
From: Borislav Petkov @ 2017-03-07 0:50 UTC (permalink / raw)
To: Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, paul.gortmaker, hpa, cl,
dan.j.williams, aarcange, sfr, andriy.shevchenko, herbert, bhe,
xemul, joro, x86, peterz, piotr.luc, mingo, msalter, ross.zwisler,
dyoung, thomas.lendacky, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, bhelgaas, tglx, mchehab,
iamjoonsoo.kim, labbott
In-Reply-To: <148846756856.2349.18360437323368784256.stgit@brijesh-build-machine>
On Thu, Mar 02, 2017 at 10:12:48AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> 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 <thomas.lendacky@amd.com>
> ---
> 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_ENABLE BIT(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_UNHALT 7
> +#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)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data
From: Bjorn Helgaas @ 2017-03-07 0:03 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-efi, Brijesh Singh, labbott, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, hpa, cl, tglx, aarcange, sfr,
mchehab, simon.guinot, bhe, xemul, joro, x86, peterz, piotr.luc,
mingo, msalter, ross.zwisler, bp, dyoung, jroedel, keescook, arnd,
toshi.kani, mathieu.desnoyers, luto, pbonzini, bhelgaas,
dan.j.williams, andriy.shevchenko, akpm, herbert
In-Reply-To: <df526224-0a4b-abc6-6377-efbca77284b1@amd.com>
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 <thomas.lendacky@amd.com>
> >>
> >>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 <thomas.lendacky@amd.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> >>---
> >> 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);
> >>
^ permalink raw reply
* Re: [PATCH v3] MIPS: Fix build breakage caused by header file changes
From: James Hogan @ 2017-03-06 23:20 UTC (permalink / raw)
To: Guenter Roeck
Cc: Ralf Baechle, Herbert Xu, linux-mips, linux-kernel, linux-crypto,
Ingo Molnar
In-Reply-To: <1488827635-7708-1-git-send-email-linux@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 5772 bytes --]
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 <linux/sched.h> to <linux/sched/task_stack.h>") and commit
> f780d89a0e82 ("sched/headers: Remove <asm/ptrace.h> from
> <linux/sched.h>"), 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 <asm/fpu.h> 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 <asm/ptrace.h> from ...")
> Cc: Ingo Molnar <mingo@kernel.org>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> 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 <linux/irqflags.h>
> #include <linux/notifier.h>
> #include <linux/prefetch.h>
> -#include <linux/sched.h>
> +#include <linux/ptrace.h>
> +#include <linux/sched/task_stack.h>
>
> #include <asm/cop2.h>
> #include <asm/current.h>
> 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 <asm/cop2.h>
> #include <linux/export.h>
> #include <linux/interrupt.h>
> +#include <linux/sched/task_stack.h>
>
> #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 <linux/smp.h>
> #include <linux/interrupt.h>
> #include <linux/kernel_stat.h>
> -#include <linux/sched.h>
> #include <linux/sched/hotplug.h>
> +#include <linux/sched/task_stack.h>
> #include <linux/init.h>
> #include <linux/export.h>
>
> 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 <linux/cpu_pm.h>
> #include <linux/init.h>
> +#include <linux/ptrace.h>
>
> #include <asm/dsp.h>
> #include <asm/fpu.h>
> 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 (ralf@linux-mips.org)
> */
> #include <linux/kernel.h>
> -#include <linux/sched.h>
> +#include <linux/sched/task_stack.h>
> #include <linux/cpumask.h>
> #include <linux/interrupt.h>
> #include <linux/irqchip/mips-gic.h>
> 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 <linux/init.h>
> #include <linux/smp.h>
> #include <linux/irq.h>
> +#include <linux/sched/task_stack.h>
>
> #include <asm/mmu_context.h>
>
> 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 <linux/irqflags.h>
> #include <linux/notifier.h>
> #include <linux/prefetch.h>
> -#include <linux/sched.h>
> +#include <linux/ptrace.h>
> +#include <linux/sched/task_stack.h>
>
> #include <asm/cop2.h>
> #include <asm/current.h>
> diff --git a/arch/mips/power/cpu.c b/arch/mips/power/cpu.c
> index 2129e67723ff..6ecccc26bf7f 100644
> --- a/arch/mips/power/cpu.c
> +++ b/arch/mips/power/cpu.c
> @@ -7,6 +7,7 @@
> * Author: Hu Hongbing <huhb@lemote.com>
> * Wu Zhangjin <wuzhangjin@gmail.com>
> */
> +#include <linux/ptrace.h>
> #include <asm/sections.h>
> #include <asm/fpu.h>
> #include <asm/dsp.h>
> --
> 2.7.4
>
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
From: Nathan Royce @ 2017-03-06 21:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
In-Reply-To: <20170306173511.6w3e47v4vomu7yv4@kozik-lap>
[-- Attachment #1: Type: text/plain, Size: 9163 bytes --]
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 <krzk@kernel.org> 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 00000004
>> [ 21.070966] pgd = c0004000
>> [ 21.073599] [00000004] *pgd=00000000
>> [ 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-10830000 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 : [<c0335c68>] lr : [<c0335c5c>] psr: 200c0093
>> [ 21.121131] sp : edcf7e68 ip : ec59dcf4 fp : 117ce9ac
>> [ 21.132576] r10: 244525e3 r9 : c0c0540c r8 : ec59dc00
>> [ 21.137768] r7 : 00000000 r6 : 00000400 r5 : 00000000 r4 : 00000000
>> [ 21.144267] r3 : ef49fcde r2 : 00000200 r1 : 00000200 r0 : 00000000
>> [ 21.150768] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM
>> Segment none
>> [ 21.157964] Control: 10c5387d Table: 6618c06a DAC: 00000051
>> [ 21.163677] Process irq/69-10830000 (pid: 121, stack limit = 0xedcf6218)
>> [ 21.170350] Stack: (0xedcf7e68 to 0xedcf8000)
>> [ 21.174684] 7e60: ef49fcdc ec93f200 ef49fcdc
>> ec93f200 ec59dddc 00000400
>> [ 21.182853] 7e80: 00000000 00000000 00000400 00000000 ef49fcdc
>> c01100fc 00000000 00000000
>> [ 21.190983] 7ea0: 00000000 00000000 00000000 c0110f80 00000010
>> 00000010 0000000f 00040a01
>> [ 21.199128] 7ec0: 00000000 ec59dc00 c0c0540c 00000000 00000000
>> 600c0013 00000002 00000000
>> [ 21.207274] 7ee0: ee889d20 c033608c eea21c90 c05a80d0 eea21ce8
>> eea21c90 0000000c 00040a01
>> [ 21.215418] 7f00: eea21ce8 eea21c90 0000000c 00000000 eea21ce8
>> c05a8290 00000000 00000001
>> [ 21.223564] 7f20: eea2a600 eea8a400 eea8a400 eea2a600 c016ee68
>> c0c0540c 00000000 c016ee84
>> [ 21.231710] 7f40: edcf6000 eea2a624 eea8a400 c016f198 eea2a640
>> 00000000 c016ef7c 00040a01
>> [ 21.239868] 7f60: 00000000 eeb58280 edcf6000 00000000 eea2a640
>> eea2a600 c016f04c eeb582a8
>> [ 21.248000] 7f80: ee889d20 c0138710 edcf6000 eea2a640 c0138608
>> 00000000 00000000 00000000
>> [ 21.256145] 7fa0: 00000000 00000000 00000000 c0107a38 00000000
>> 00000000 00000000 00000000
>> [ 21.264291] 7fc0: 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000 00000000
>> [ 21.272428] 7fe0: 00000000 00000000 00000000 00000000 00000013
>> 00000000 00000000 00000000
>> [ 21.280580] [<c0335c68>] (post_crypt) from [<c033608c>]
>> (decrypt_done+0x4c/0x54)
>> [ 21.287946] [<c033608c>] (decrypt_done) from [<c05a80d0>]
>> (s5p_aes_complete+0x70/0xfc)
>> [ 21.295845] [<c05a80d0>] (s5p_aes_complete) from [<c05a8290>]
>> (s5p_aes_interrupt+0x134/0x1a0)
>> [ 21.304323] [<c05a8290>] (s5p_aes_interrupt) from [<c016ee84>]
>> (irq_thread_fn+0x1c/0x54)
>> [ 21.312378] [<c016ee84>] (irq_thread_fn) from [<c016f198>]
>> (irq_thread+0x14c/0x204)
>> [ 21.320004] [<c016f198>] (irq_thread) from [<c0138710>] (kthread+0x108/0x138)
>> [ 21.327109] [<c0138710>] (kthread) from [<c0107a38>]
>> (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-10830000" (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] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
>> (show_stack+0x10/0x14)
>> [ 21.896826] [<c010b408>] (show_stack) from [<c036c34c>]
>> (dump_stack+0x84/0x98)
>> [ 21.904015] [<c036c34c>] (dump_stack) from [<c01706cc>]
>> (__report_bad_irq+0x2c/0xcc)
>> [ 21.911716] [<c01706cc>] (__report_bad_irq) from [<c0170ad0>]
>> (note_interrupt+0x28c/0x2dc)
>> [ 21.919948] [<c0170ad0>] (note_interrupt) from [<c016dd20>]
>> (handle_irq_event_percpu+0x5c/0x7c)
>> [ 21.928614] [<c016dd20>] (handle_irq_event_percpu) from
>> [<c016dd78>] (handle_irq_event+0x38/0x5c)
>> [ 21.937451] [<c016dd78>] (handle_irq_event) from [<c0171470>]
>> (handle_fasteoi_irq+0xb8/0x190)
>> [ 21.945944] [<c0171470>] (handle_fasteoi_irq) from [<c016cf70>]
>> (generic_handle_irq+0x24/0x34)
>> [ 21.954522] [<c016cf70>] (generic_handle_irq) from [<c016d48c>]
>> (__handle_domain_irq+0x5c/0xb4)
>> [ 21.963188] [<c016d48c>] (__handle_domain_irq) from [<c01014e8>]
>> (gic_handle_irq+0x38/0x74)
>> [ 21.971505] [<c01014e8>] (gic_handle_irq) from [<c010bf8c>]
>> (__irq_svc+0x6c/0x90)
>> [ 21.978953] Exception stack(0xc0c01e68 to 0xc0c01eb0)
>> [ 21.983975] 1e60: 00200102 c0c5cec0 00000000
>> 00000000 00000040 00000000
>> [ 21.992127] 1e80: c0c00000 00000001 c0c02080 c0c00000 00000000
>> efffc7c0 c0c01f00 c0c01eb8
>> [ 22.000271] 1ea0: c0120b58 c01206d4 600e0113 ffffffff
>> [ 22.005299] [<c010bf8c>] (__irq_svc) from [<c01206d4>]
>> (__do_softirq+0x90/0x21c)
>> [ 22.012667] [<c01206d4>] (__do_softirq) from [<c0120b58>]
>> (irq_exit+0xd8/0x140)
>> [ 22.019945] [<c0120b58>] (irq_exit) from [<c016d490>]
>> (__handle_domain_irq+0x60/0xb4)
>> [ 22.027743] [<c016d490>] (__handle_domain_irq) from [<c01014e8>]
>> (gic_handle_irq+0x38/0x74)
>> [ 22.036061] [<c01014e8>] (gic_handle_irq) from [<c010bf8c>]
>> (__irq_svc+0x6c/0x90)
>> [ 22.043510] Exception stack(0xc0c01f38 to 0xc0c01f80)
>> [ 22.048529] 1f20:
>> 00000001 00000000
>> [ 22.056685] 1f40: 00000000 c0114e60 c0c00000 c0c05490 c0c0542c
>> c0b4ff88 c0c01f90 00000000
>> [ 22.064832] 1f60: 00000000 efffc7c0 600e0013 c0c01f88 c0108480
>> c0108484 600e0013 ffffffff
>> [ 22.072978] [<c010bf8c>] (__irq_svc) from [<c0108484>]
>> (arch_cpu_idle+0x38/0x3c)
>> [ 22.080347] [<c0108484>] (arch_cpu_idle) from [<c015da70>]
>> (do_idle+0x164/0x1f8)
>> [ 22.087708] [<c015da70>] (do_idle) from [<c015dda0>]
>> (cpu_startup_entry+0x18/0x1c)
>> [ 22.095258] [<c015dda0>] (cpu_startup_entry) from [<c0b00c74>]
>> (start_kernel+0x374/0x394)
>> [ 22.103389] handlers:
>> [ 22.105635] [<c016dde8>] irq_default_primary_handler threaded
>> [<c05a815c>] s5p_aes_interrupt
>> [ 22.114046] Disabling IRQ #69
>> [ 23.496638] Btrfs loaded, crc32c=crc32c-generic
>> *****
>> Do I need to add "irqpoll" to my u-boot boot config now?
>>
>> Yeah, the mailing list bounced my original email because I wasn't
>> using plain-text, but my full post shows in Herbert's reply.
[-- Attachment #2: config-4.10.0.gz --]
[-- Type: application/x-gzip, Size: 28178 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature
From: Borislav Petkov @ 2017-03-06 20:54 UTC (permalink / raw)
To: Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, paul.gortmaker, hpa, cl,
dan.j.williams, aarcange, sfr, andriy.shevchenko, herbert, bhe,
xemul, joro, x86, peterz, piotr.luc, mingo, msalter, ross.zwisler,
dyoung, thomas.lendacky, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, bhelgaas, tglx, mchehab,
iamjoonsoo.kim, labbott
In-Reply-To: <148882363019.12034.4647462304803229954.stgit@brijesh-build-machine>
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)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/1] ARM: dts: NSP: Add crypto (SPU) to dtsi
From: Florian Fainelli @ 2017-03-06 19:22 UTC (permalink / raw)
To: Florian Fainelli, Steve Lin,
herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
ray.jui-dY08KVG/lbpWk0Htik3J/w,
scott.branden-dY08KVG/lbpWk0Htik3J/w,
jon.mason-dY08KVG/lbpWk0Htik3J/w, mark.rutland-5wv7dgnIgG8
Cc: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
rob.rice-dY08KVG/lbpWk0Htik3J/w,
linux-crypto-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <66ba937a-f1c3-1cae-ff2e-46a9d9c97344-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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 <steven.lin1-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3] MIPS: Fix build breakage caused by header file changes
From: Guenter Roeck @ 2017-03-06 19:13 UTC (permalink / raw)
To: Ralf Baechle
Cc: Herbert Xu, linux-mips, linux-kernel, linux-crypto, Guenter Roeck,
Ingo Molnar
Since commit f3ac60671954 ("sched/headers: Move task-stack related
APIs from <linux/sched.h> to <linux/sched/task_stack.h>") and commit
f780d89a0e82 ("sched/headers: Remove <asm/ptrace.h> from
<linux/sched.h>"), 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 <asm/ptrace.h> from ...")
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
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 <linux/irqflags.h>
#include <linux/notifier.h>
#include <linux/prefetch.h>
-#include <linux/sched.h>
+#include <linux/ptrace.h>
+#include <linux/sched/task_stack.h>
#include <asm/cop2.h>
#include <asm/current.h>
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 <asm/cop2.h>
#include <linux/export.h>
#include <linux/interrupt.h>
+#include <linux/sched/task_stack.h>
#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 <linux/smp.h>
#include <linux/interrupt.h>
#include <linux/kernel_stat.h>
-#include <linux/sched.h>
#include <linux/sched/hotplug.h>
+#include <linux/sched/task_stack.h>
#include <linux/init.h>
#include <linux/export.h>
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 <linux/cpu_pm.h>
#include <linux/init.h>
+#include <linux/ptrace.h>
#include <asm/dsp.h>
#include <asm/fpu.h>
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 (ralf@linux-mips.org)
*/
#include <linux/kernel.h>
-#include <linux/sched.h>
+#include <linux/sched/task_stack.h>
#include <linux/cpumask.h>
#include <linux/interrupt.h>
#include <linux/irqchip/mips-gic.h>
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 <linux/init.h>
#include <linux/smp.h>
#include <linux/irq.h>
+#include <linux/sched/task_stack.h>
#include <asm/mmu_context.h>
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 <linux/irqflags.h>
#include <linux/notifier.h>
#include <linux/prefetch.h>
-#include <linux/sched.h>
+#include <linux/ptrace.h>
+#include <linux/sched/task_stack.h>
#include <asm/cop2.h>
#include <asm/current.h>
diff --git a/arch/mips/power/cpu.c b/arch/mips/power/cpu.c
index 2129e67723ff..6ecccc26bf7f 100644
--- a/arch/mips/power/cpu.c
+++ b/arch/mips/power/cpu.c
@@ -7,6 +7,7 @@
* Author: Hu Hongbing <huhb@lemote.com>
* Wu Zhangjin <wuzhangjin@gmail.com>
*/
+#include <linux/ptrace.h>
#include <asm/sections.h>
#include <asm/fpu.h>
#include <asm/dsp.h>
--
2.7.4
^ permalink raw reply related
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
From: Krzysztof Kozlowski @ 2017-03-06 17:35 UTC (permalink / raw)
To: Nathan Royce
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
In-Reply-To: <CALaQ_hpC4G6CaxZAFvwNG3gFjc5Dj1C7zB6b_WQjGeYhbArHKw@mail.gmail.com>
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 00000004
> [ 21.070966] pgd = c0004000
> [ 21.073599] [00000004] *pgd=00000000
> [ 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-10830000 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 : [<c0335c68>] lr : [<c0335c5c>] psr: 200c0093
> [ 21.121131] sp : edcf7e68 ip : ec59dcf4 fp : 117ce9ac
> [ 21.132576] r10: 244525e3 r9 : c0c0540c r8 : ec59dc00
> [ 21.137768] r7 : 00000000 r6 : 00000400 r5 : 00000000 r4 : 00000000
> [ 21.144267] r3 : ef49fcde r2 : 00000200 r1 : 00000200 r0 : 00000000
> [ 21.150768] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM
> Segment none
> [ 21.157964] Control: 10c5387d Table: 6618c06a DAC: 00000051
> [ 21.163677] Process irq/69-10830000 (pid: 121, stack limit = 0xedcf6218)
> [ 21.170350] Stack: (0xedcf7e68 to 0xedcf8000)
> [ 21.174684] 7e60: ef49fcdc ec93f200 ef49fcdc
> ec93f200 ec59dddc 00000400
> [ 21.182853] 7e80: 00000000 00000000 00000400 00000000 ef49fcdc
> c01100fc 00000000 00000000
> [ 21.190983] 7ea0: 00000000 00000000 00000000 c0110f80 00000010
> 00000010 0000000f 00040a01
> [ 21.199128] 7ec0: 00000000 ec59dc00 c0c0540c 00000000 00000000
> 600c0013 00000002 00000000
> [ 21.207274] 7ee0: ee889d20 c033608c eea21c90 c05a80d0 eea21ce8
> eea21c90 0000000c 00040a01
> [ 21.215418] 7f00: eea21ce8 eea21c90 0000000c 00000000 eea21ce8
> c05a8290 00000000 00000001
> [ 21.223564] 7f20: eea2a600 eea8a400 eea8a400 eea2a600 c016ee68
> c0c0540c 00000000 c016ee84
> [ 21.231710] 7f40: edcf6000 eea2a624 eea8a400 c016f198 eea2a640
> 00000000 c016ef7c 00040a01
> [ 21.239868] 7f60: 00000000 eeb58280 edcf6000 00000000 eea2a640
> eea2a600 c016f04c eeb582a8
> [ 21.248000] 7f80: ee889d20 c0138710 edcf6000 eea2a640 c0138608
> 00000000 00000000 00000000
> [ 21.256145] 7fa0: 00000000 00000000 00000000 c0107a38 00000000
> 00000000 00000000 00000000
> [ 21.264291] 7fc0: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
> [ 21.272428] 7fe0: 00000000 00000000 00000000 00000000 00000013
> 00000000 00000000 00000000
> [ 21.280580] [<c0335c68>] (post_crypt) from [<c033608c>]
> (decrypt_done+0x4c/0x54)
> [ 21.287946] [<c033608c>] (decrypt_done) from [<c05a80d0>]
> (s5p_aes_complete+0x70/0xfc)
> [ 21.295845] [<c05a80d0>] (s5p_aes_complete) from [<c05a8290>]
> (s5p_aes_interrupt+0x134/0x1a0)
> [ 21.304323] [<c05a8290>] (s5p_aes_interrupt) from [<c016ee84>]
> (irq_thread_fn+0x1c/0x54)
> [ 21.312378] [<c016ee84>] (irq_thread_fn) from [<c016f198>]
> (irq_thread+0x14c/0x204)
> [ 21.320004] [<c016f198>] (irq_thread) from [<c0138710>] (kthread+0x108/0x138)
> [ 21.327109] [<c0138710>] (kthread) from [<c0107a38>]
> (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-10830000" (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] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
> (show_stack+0x10/0x14)
> [ 21.896826] [<c010b408>] (show_stack) from [<c036c34c>]
> (dump_stack+0x84/0x98)
> [ 21.904015] [<c036c34c>] (dump_stack) from [<c01706cc>]
> (__report_bad_irq+0x2c/0xcc)
> [ 21.911716] [<c01706cc>] (__report_bad_irq) from [<c0170ad0>]
> (note_interrupt+0x28c/0x2dc)
> [ 21.919948] [<c0170ad0>] (note_interrupt) from [<c016dd20>]
> (handle_irq_event_percpu+0x5c/0x7c)
> [ 21.928614] [<c016dd20>] (handle_irq_event_percpu) from
> [<c016dd78>] (handle_irq_event+0x38/0x5c)
> [ 21.937451] [<c016dd78>] (handle_irq_event) from [<c0171470>]
> (handle_fasteoi_irq+0xb8/0x190)
> [ 21.945944] [<c0171470>] (handle_fasteoi_irq) from [<c016cf70>]
> (generic_handle_irq+0x24/0x34)
> [ 21.954522] [<c016cf70>] (generic_handle_irq) from [<c016d48c>]
> (__handle_domain_irq+0x5c/0xb4)
> [ 21.963188] [<c016d48c>] (__handle_domain_irq) from [<c01014e8>]
> (gic_handle_irq+0x38/0x74)
> [ 21.971505] [<c01014e8>] (gic_handle_irq) from [<c010bf8c>]
> (__irq_svc+0x6c/0x90)
> [ 21.978953] Exception stack(0xc0c01e68 to 0xc0c01eb0)
> [ 21.983975] 1e60: 00200102 c0c5cec0 00000000
> 00000000 00000040 00000000
> [ 21.992127] 1e80: c0c00000 00000001 c0c02080 c0c00000 00000000
> efffc7c0 c0c01f00 c0c01eb8
> [ 22.000271] 1ea0: c0120b58 c01206d4 600e0113 ffffffff
> [ 22.005299] [<c010bf8c>] (__irq_svc) from [<c01206d4>]
> (__do_softirq+0x90/0x21c)
> [ 22.012667] [<c01206d4>] (__do_softirq) from [<c0120b58>]
> (irq_exit+0xd8/0x140)
> [ 22.019945] [<c0120b58>] (irq_exit) from [<c016d490>]
> (__handle_domain_irq+0x60/0xb4)
> [ 22.027743] [<c016d490>] (__handle_domain_irq) from [<c01014e8>]
> (gic_handle_irq+0x38/0x74)
> [ 22.036061] [<c01014e8>] (gic_handle_irq) from [<c010bf8c>]
> (__irq_svc+0x6c/0x90)
> [ 22.043510] Exception stack(0xc0c01f38 to 0xc0c01f80)
> [ 22.048529] 1f20:
> 00000001 00000000
> [ 22.056685] 1f40: 00000000 c0114e60 c0c00000 c0c05490 c0c0542c
> c0b4ff88 c0c01f90 00000000
> [ 22.064832] 1f60: 00000000 efffc7c0 600e0013 c0c01f88 c0108480
> c0108484 600e0013 ffffffff
> [ 22.072978] [<c010bf8c>] (__irq_svc) from [<c0108484>]
> (arch_cpu_idle+0x38/0x3c)
> [ 22.080347] [<c0108484>] (arch_cpu_idle) from [<c015da70>]
> (do_idle+0x164/0x1f8)
> [ 22.087708] [<c015da70>] (do_idle) from [<c015dda0>]
> (cpu_startup_entry+0x18/0x1c)
> [ 22.095258] [<c015dda0>] (cpu_startup_entry) from [<c0b00c74>]
> (start_kernel+0x374/0x394)
> [ 22.103389] handlers:
> [ 22.105635] [<c016dde8>] irq_default_primary_handler threaded
> [<c05a815c>] s5p_aes_interrupt
> [ 22.114046] Disabling IRQ #69
> [ 23.496638] Btrfs loaded, crc32c=crc32c-generic
> *****
> Do I need to add "irqpoll" to my u-boot boot config now?
>
> Yeah, the mailing list bounced my original email because I wasn't
> using plain-text, but my full post shows in Herbert's reply.
>
> On Sun, Mar 5, 2017 at 11:16 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Fri, Mar 03, 2017 at 12:02:10PM +0800, Herbert Xu wrote:
> >> On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote:
> >> > ARM ODroid XU4
> >> >
> >> > $ cat /proc/config.gz | gunzip | grep XTS
> >> > CONFIG_CRYPTO_XTS=y
> >> >
> >> > $ grep xts /proc/crypto
> >> > //4.9.13
> >> > name : xts(aes)
> >> > driver : xts(aes-generic)
> >> > //4.10.1
> >> > <blank>
> >> > //cbc can be found though
> >> >
> >> > CRYPTTAB:
> >> > cryptswap1 UUID=<sanitized> /dev/urandom
> >> > swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail
> >> >
> >> > FSTAB:
> >> > /dev/mapper/cryptswap1 none swap sw 0 0
> >> >
> >> > Boot Log:
> >> > [ 10.535985] ------------[ cut here ]------------
> >> > [ 10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430
> >> > skcipher_walk_first+0x13c/0x14c
> >> > [ 10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate
> >> > dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
> >> > ip_tables x_tables
> >> > [ 10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1
> >> > [ 10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> >> > [ 10.574171] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
> >> > (show_stack+0x10/0x14)
> >> > [ 10.581893] [<c010b408>] (show_stack) from [<c036772c>]
> >> > (dump_stack+0x84/0x98)
> >> > [ 10.589073] [<c036772c>] (dump_stack) from [<c011bb20>]
> >> > (__warn+0xe8/0x100)
> >> > [ 10.595975] [<c011bb20>] (__warn) from [<c011bc30>]
> >> > (warn_slowpath_null+0x20/0x28)
> >> > [ 10.603546] [<c011bc30>] (warn_slowpath_null) from [<c0329a48>]
> >> > (skcipher_walk_first+0x13c/0x14c)
> >> > [ 10.612390] [<c0329a48>] (skcipher_walk_first) from [<c0329b30>]
> >> > (skcipher_walk_virt+0x1c/0x38)
> >> > [ 10.621056] [<c0329b30>] (skcipher_walk_virt) from [<c0330ed0>]
> >> > (post_crypt+0x38/0x1c4)
> >> > [ 10.629022] [<c0330ed0>] (post_crypt) from [<c0331470>]
> >> > (decrypt_done+0x4c/0x54)
> >> > [ 10.636389] [<c0331470>] (decrypt_done) from [<c05a03f0>]
> >> > (s5p_aes_complete+0x70/0xfc)
> >> > [ 10.644274] [<c05a03f0>] (s5p_aes_complete) from [<c05a05b0>]
> >> > (s5p_aes_interrupt+0x134/0x1a0)
> >> > [ 10.652771] [<c05a05b0>] (s5p_aes_interrupt) from [<c016dc3c>]
> >> > (__handle_irq_event_percpu+0x9c/0x124)
> >>
> >> This looks like a bug in the s5p driver. It's calling the completion
> >> function straight from the IRQ handler, which is triggering the
> >> sanity check in skcipher_walk_first.
> >>
> >> The s5p driver needs to schedule a tasklet to call the completion
> >> function.
> >
> > Tasklet... or threaded IRQ handler maybe? I sent a fix.
> >
> > BTW, I subscribe the crypto list but I could not find the original email
> > there.
> >
> > Best regards,
> > Krzysztof
> >
^ permalink raw reply
* Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature
From: Brijesh Singh @ 2017-03-06 18:11 UTC (permalink / raw)
To: bp
Cc: linux-efi, brijesh.singh, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, hpa, cl, tglx, aarcange, sfr,
mchehab, simon.guinot, bhe, xemul, joro, x86, peterz, piotr.luc,
mingo, msalter, ross.zwisler, labbott, dyoung, thomas.lendacky,
jroedel, keescook, arnd, toshi.kani, mathieu.desnoyers, luto,
pbonzini, bhelgaas, dan.j.williams, andriy.shevchenko, akpm,
herbert, t
In-Reply-To: <20170304101113.k6ontjjbljanm6tv@pd.tnic>
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 0x8000001f reports information related to SME:
@@ -17,13 +17,14 @@ function 0x8000001f reports information related to SME:
0x8000001f[eax]:
Bit[0] indicates support for SME
0x8000001f[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 encryption support. If the BIOS
-merely enables SME (sets bit 23 of the SYS_CFG MSR), then Linux can activate
-memory encryption. However, if BIOS does not enable SME, then Linux will not
-attempt to activate memory encryption, even if configured to do so by default
-or the mem_encrypt=on command line parameter is specified.
+merely enables SME (sets bit 23 of the MSR_K8_SYSCFG), then Linux can activate
+memory encryption by default (CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y) or
+by supplying mem_encrypt=on on the kernel command line. However, if BIOS does
+not enable SME, then Linux will not be able to activate memory encryption, even
+if configured to do so by default or the mem_encrypt=on command line parameter
+is specified.
diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index ea2de6a..d59c15c 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -28,7 +28,6 @@ enum cpuid_leafs
CPUID_8000_000A_EDX,
CPUID_7_ECX,
CPUID_8000_0007_EBX,
- CPUID_8000_001F_EAX,
};
#ifdef CONFIG_X86_FEATURE_NAMES
@@ -79,9 +78,8 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 15, feature_bit) || \
CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 16, feature_bit) || \
CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 17, feature_bit) || \
- CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 18, feature_bit) || \
REQUIRED_MASK_CHECK || \
- BUILD_BUG_ON_ZERO(NCAPINTS != 19))
+ BUILD_BUG_ON_ZERO(NCAPINTS != 18))
#define DISABLED_MASK_BIT_SET(feature_bit) \
( CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 0, feature_bit) || \
@@ -102,9 +100,8 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 15, feature_bit) || \
CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 16, feature_bit) || \
CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 17, feature_bit) || \
- CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 18, feature_bit) || \
DISABLED_MASK_CHECK || \
- BUILD_BUG_ON_ZERO(NCAPINTS != 19))
+ BUILD_BUG_ON_ZERO(NCAPINTS != 18))
#define cpu_has(c, bit) \
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 331fb81..b1a4468 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -12,7 +12,7 @@
/*
* Defines x86 CPU feature bits
*/
-#define NCAPINTS 19 /* N 32-bit words worth of info */
+#define NCAPINTS 18 /* N 32-bit words worth of info */
#define NBUGINTS 1 /* N 32-bit bug flags */
/*
@@ -187,6 +187,7 @@
* Reuse free bits when adding new feature flags!
*/
+#define X86_FEATURE_SME ( 7*32+ 0) /* AMD Secure Memory Encryption */
#define X86_FEATURE_CPB ( 7*32+ 2) /* AMD Core Performance Boost */
#define X86_FEATURE_EPB ( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS support */
#define X86_FEATURE_CAT_L3 ( 7*32+ 4) /* Cache Allocation Technology L3 */
@@ -296,9 +297,6 @@
#define X86_FEATURE_SUCCOR (17*32+1) /* Uncorrectable error containment and recovery */
#define X86_FEATURE_SMCA (17*32+3) /* Scalable MCA */
-/* AMD-defined CPU features, CPUID level 0x8000001f (eax), word 18 */
-#define X86_FEATURE_SME (18*32+0) /* Secure Memory Encryption */
-
/*
* BUG word(s)
*/
diff --git a/arch/x86/include/asm/disabled-features.h b/arch/x86/include/asm/disabled-features.h
index 8b45e08..85599ad 100644
--- a/arch/x86/include/asm/disabled-features.h
+++ b/arch/x86/include/asm/disabled-features.h
@@ -57,7 +57,6 @@
#define DISABLED_MASK15 0
#define DISABLED_MASK16 (DISABLE_PKU|DISABLE_OSPKE)
#define DISABLED_MASK17 0
-#define DISABLED_MASK18 0
-#define DISABLED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 19)
+#define DISABLED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 18)
#endif /* _ASM_X86_DISABLED_FEATURES_H */
diff --git a/arch/x86/include/asm/required-features.h b/arch/x86/include/asm/required-features.h
index 6847d85..fac9a5c 100644
--- a/arch/x86/include/asm/required-features.h
+++ b/arch/x86/include/asm/required-features.h
@@ -100,7 +100,6 @@
#define REQUIRED_MASK15 0
#define REQUIRED_MASK16 0
#define REQUIRED_MASK17 0
-#define REQUIRED_MASK18 0
-#define REQUIRED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 19)
+#define REQUIRED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 18)
#endif /* _ASM_X86_REQUIRED_FEATURES_H */
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 35a5d5d..6bddda3 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -615,6 +615,29 @@ static void early_init_amd(struct cpuinfo_x86 *c)
*/
if (cpu_has_amd_erratum(c, amd_erratum_400))
set_cpu_bug(c, X86_BUG_AMD_E400);
+
+ /*
+ * BIOS support is required for SME. If BIOS has enabld SME then
+ * adjust x86_phys_bits by the SME physical address space reduction
+ * value. If BIOS has not enabled SME then don't advertise the
+ * feature (set in scattered.c).
+ */
+ if (c->extended_cpuid_level >= 0x8000001f) {
+ if (cpu_has(c, X86_FEATURE_SME)) {
+ u64 msr;
+
+ /* Check if SME is enabled */
+ rdmsrl(MSR_K8_SYSCFG, msr);
+ if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT) {
+ unsigned int ebx;
+
+ ebx = cpuid_ebx(0x8000001f);
+ c->x86_phys_bits -= (ebx >> 6) & 0x3f;
+ } else {
+ clear_cpu_cap(c, X86_FEATURE_SME);
+ }
+ }
+ }
}
static void init_amd_k8(struct cpuinfo_x86 *c)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 358208d7..c188ae5 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -763,29 +763,6 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
if (c->extended_cpuid_level >= 0x8000000a)
c->x86_capability[CPUID_8000_000A_EDX] = cpuid_edx(0x8000000a);
- if (c->extended_cpuid_level >= 0x8000001f) {
- cpuid(0x8000001f, &eax, &ebx, &ecx, &edx);
-
- /* SME feature support */
- if ((c->x86_vendor == X86_VENDOR_AMD) && (eax & 0x01)) {
- u64 msr;
-
- /*
- * For SME, BIOS support is required. If BIOS has
- * enabled SME adjust x86_phys_bits by the SME
- * physical address space reduction value. If BIOS
- * has not enabled SME don't advertise the feature.
- */
- rdmsrl(MSR_K8_SYSCFG, msr);
- if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT)
- c->x86_phys_bits -= (ebx >> 6) & 0x3f;
- else
- eax &= ~0x01;
- }
-
- c->x86_capability[CPUID_8000_001F_EAX] = eax;
- }
-
init_scattered_cpuid_features(c);
/*
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index d979406..cabda87 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -30,6 +30,7 @@ static const struct cpuid_bit cpuid_bits[] = {
{ X86_FEATURE_HW_PSTATE, CPUID_EDX, 7, 0x80000007, 0 },
{ X86_FEATURE_CPB, CPUID_EDX, 9, 0x80000007, 0 },
{ X86_FEATURE_PROC_FEEDBACK, CPUID_EDX, 11, 0x80000007, 0 },
+ { X86_FEATURE_SME, CPUID_EAX, 0, 0x8000001f, 0 },
{ 0, 0, 0, 0, 0 }
};
^ permalink raw reply related
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
From: Nathan Royce @ 2017-03-06 16:18 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
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 00000004
[ 21.070966] pgd = c0004000
[ 21.073599] [00000004] *pgd=00000000
[ 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-10830000 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 : [<c0335c68>] lr : [<c0335c5c>] psr: 200c0093
[ 21.121131] sp : edcf7e68 ip : ec59dcf4 fp : 117ce9ac
[ 21.132576] r10: 244525e3 r9 : c0c0540c r8 : ec59dc00
[ 21.137768] r7 : 00000000 r6 : 00000400 r5 : 00000000 r4 : 00000000
[ 21.144267] r3 : ef49fcde r2 : 00000200 r1 : 00000200 r0 : 00000000
[ 21.150768] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment none
[ 21.157964] Control: 10c5387d Table: 6618c06a DAC: 00000051
[ 21.163677] Process irq/69-10830000 (pid: 121, stack limit = 0xedcf6218)
[ 21.170350] Stack: (0xedcf7e68 to 0xedcf8000)
[ 21.174684] 7e60: ef49fcdc ec93f200 ef49fcdc
ec93f200 ec59dddc 00000400
[ 21.182853] 7e80: 00000000 00000000 00000400 00000000 ef49fcdc
c01100fc 00000000 00000000
[ 21.190983] 7ea0: 00000000 00000000 00000000 c0110f80 00000010
00000010 0000000f 00040a01
[ 21.199128] 7ec0: 00000000 ec59dc00 c0c0540c 00000000 00000000
600c0013 00000002 00000000
[ 21.207274] 7ee0: ee889d20 c033608c eea21c90 c05a80d0 eea21ce8
eea21c90 0000000c 00040a01
[ 21.215418] 7f00: eea21ce8 eea21c90 0000000c 00000000 eea21ce8
c05a8290 00000000 00000001
[ 21.223564] 7f20: eea2a600 eea8a400 eea8a400 eea2a600 c016ee68
c0c0540c 00000000 c016ee84
[ 21.231710] 7f40: edcf6000 eea2a624 eea8a400 c016f198 eea2a640
00000000 c016ef7c 00040a01
[ 21.239868] 7f60: 00000000 eeb58280 edcf6000 00000000 eea2a640
eea2a600 c016f04c eeb582a8
[ 21.248000] 7f80: ee889d20 c0138710 edcf6000 eea2a640 c0138608
00000000 00000000 00000000
[ 21.256145] 7fa0: 00000000 00000000 00000000 c0107a38 00000000
00000000 00000000 00000000
[ 21.264291] 7fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 21.272428] 7fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 21.280580] [<c0335c68>] (post_crypt) from [<c033608c>]
(decrypt_done+0x4c/0x54)
[ 21.287946] [<c033608c>] (decrypt_done) from [<c05a80d0>]
(s5p_aes_complete+0x70/0xfc)
[ 21.295845] [<c05a80d0>] (s5p_aes_complete) from [<c05a8290>]
(s5p_aes_interrupt+0x134/0x1a0)
[ 21.304323] [<c05a8290>] (s5p_aes_interrupt) from [<c016ee84>]
(irq_thread_fn+0x1c/0x54)
[ 21.312378] [<c016ee84>] (irq_thread_fn) from [<c016f198>]
(irq_thread+0x14c/0x204)
[ 21.320004] [<c016f198>] (irq_thread) from [<c0138710>] (kthread+0x108/0x138)
[ 21.327109] [<c0138710>] (kthread) from [<c0107a38>]
(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-10830000" (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] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
(show_stack+0x10/0x14)
[ 21.896826] [<c010b408>] (show_stack) from [<c036c34c>]
(dump_stack+0x84/0x98)
[ 21.904015] [<c036c34c>] (dump_stack) from [<c01706cc>]
(__report_bad_irq+0x2c/0xcc)
[ 21.911716] [<c01706cc>] (__report_bad_irq) from [<c0170ad0>]
(note_interrupt+0x28c/0x2dc)
[ 21.919948] [<c0170ad0>] (note_interrupt) from [<c016dd20>]
(handle_irq_event_percpu+0x5c/0x7c)
[ 21.928614] [<c016dd20>] (handle_irq_event_percpu) from
[<c016dd78>] (handle_irq_event+0x38/0x5c)
[ 21.937451] [<c016dd78>] (handle_irq_event) from [<c0171470>]
(handle_fasteoi_irq+0xb8/0x190)
[ 21.945944] [<c0171470>] (handle_fasteoi_irq) from [<c016cf70>]
(generic_handle_irq+0x24/0x34)
[ 21.954522] [<c016cf70>] (generic_handle_irq) from [<c016d48c>]
(__handle_domain_irq+0x5c/0xb4)
[ 21.963188] [<c016d48c>] (__handle_domain_irq) from [<c01014e8>]
(gic_handle_irq+0x38/0x74)
[ 21.971505] [<c01014e8>] (gic_handle_irq) from [<c010bf8c>]
(__irq_svc+0x6c/0x90)
[ 21.978953] Exception stack(0xc0c01e68 to 0xc0c01eb0)
[ 21.983975] 1e60: 00200102 c0c5cec0 00000000
00000000 00000040 00000000
[ 21.992127] 1e80: c0c00000 00000001 c0c02080 c0c00000 00000000
efffc7c0 c0c01f00 c0c01eb8
[ 22.000271] 1ea0: c0120b58 c01206d4 600e0113 ffffffff
[ 22.005299] [<c010bf8c>] (__irq_svc) from [<c01206d4>]
(__do_softirq+0x90/0x21c)
[ 22.012667] [<c01206d4>] (__do_softirq) from [<c0120b58>]
(irq_exit+0xd8/0x140)
[ 22.019945] [<c0120b58>] (irq_exit) from [<c016d490>]
(__handle_domain_irq+0x60/0xb4)
[ 22.027743] [<c016d490>] (__handle_domain_irq) from [<c01014e8>]
(gic_handle_irq+0x38/0x74)
[ 22.036061] [<c01014e8>] (gic_handle_irq) from [<c010bf8c>]
(__irq_svc+0x6c/0x90)
[ 22.043510] Exception stack(0xc0c01f38 to 0xc0c01f80)
[ 22.048529] 1f20:
00000001 00000000
[ 22.056685] 1f40: 00000000 c0114e60 c0c00000 c0c05490 c0c0542c
c0b4ff88 c0c01f90 00000000
[ 22.064832] 1f60: 00000000 efffc7c0 600e0013 c0c01f88 c0108480
c0108484 600e0013 ffffffff
[ 22.072978] [<c010bf8c>] (__irq_svc) from [<c0108484>]
(arch_cpu_idle+0x38/0x3c)
[ 22.080347] [<c0108484>] (arch_cpu_idle) from [<c015da70>]
(do_idle+0x164/0x1f8)
[ 22.087708] [<c015da70>] (do_idle) from [<c015dda0>]
(cpu_startup_entry+0x18/0x1c)
[ 22.095258] [<c015dda0>] (cpu_startup_entry) from [<c0b00c74>]
(start_kernel+0x374/0x394)
[ 22.103389] handlers:
[ 22.105635] [<c016dde8>] irq_default_primary_handler threaded
[<c05a815c>] s5p_aes_interrupt
[ 22.114046] Disabling IRQ #69
[ 23.496638] Btrfs loaded, crc32c=crc32c-generic
*****
Do I need to add "irqpoll" to my u-boot boot config now?
Yeah, the mailing list bounced my original email because I wasn't
using plain-text, but my full post shows in Herbert's reply.
On Sun, Mar 5, 2017 at 11:16 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Fri, Mar 03, 2017 at 12:02:10PM +0800, Herbert Xu wrote:
>> On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote:
>> > ARM ODroid XU4
>> >
>> > $ cat /proc/config.gz | gunzip | grep XTS
>> > CONFIG_CRYPTO_XTS=y
>> >
>> > $ grep xts /proc/crypto
>> > //4.9.13
>> > name : xts(aes)
>> > driver : xts(aes-generic)
>> > //4.10.1
>> > <blank>
>> > //cbc can be found though
>> >
>> > CRYPTTAB:
>> > cryptswap1 UUID=<sanitized> /dev/urandom
>> > swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail
>> >
>> > FSTAB:
>> > /dev/mapper/cryptswap1 none swap sw 0 0
>> >
>> > Boot Log:
>> > [ 10.535985] ------------[ cut here ]------------
>> > [ 10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430
>> > skcipher_walk_first+0x13c/0x14c
>> > [ 10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate
>> > dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
>> > ip_tables x_tables
>> > [ 10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1
>> > [ 10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> > [ 10.574171] [<c010eb54>] (unwind_backtrace) from [<c010b408>]
>> > (show_stack+0x10/0x14)
>> > [ 10.581893] [<c010b408>] (show_stack) from [<c036772c>]
>> > (dump_stack+0x84/0x98)
>> > [ 10.589073] [<c036772c>] (dump_stack) from [<c011bb20>]
>> > (__warn+0xe8/0x100)
>> > [ 10.595975] [<c011bb20>] (__warn) from [<c011bc30>]
>> > (warn_slowpath_null+0x20/0x28)
>> > [ 10.603546] [<c011bc30>] (warn_slowpath_null) from [<c0329a48>]
>> > (skcipher_walk_first+0x13c/0x14c)
>> > [ 10.612390] [<c0329a48>] (skcipher_walk_first) from [<c0329b30>]
>> > (skcipher_walk_virt+0x1c/0x38)
>> > [ 10.621056] [<c0329b30>] (skcipher_walk_virt) from [<c0330ed0>]
>> > (post_crypt+0x38/0x1c4)
>> > [ 10.629022] [<c0330ed0>] (post_crypt) from [<c0331470>]
>> > (decrypt_done+0x4c/0x54)
>> > [ 10.636389] [<c0331470>] (decrypt_done) from [<c05a03f0>]
>> > (s5p_aes_complete+0x70/0xfc)
>> > [ 10.644274] [<c05a03f0>] (s5p_aes_complete) from [<c05a05b0>]
>> > (s5p_aes_interrupt+0x134/0x1a0)
>> > [ 10.652771] [<c05a05b0>] (s5p_aes_interrupt) from [<c016dc3c>]
>> > (__handle_irq_event_percpu+0x9c/0x124)
>>
>> This looks like a bug in the s5p driver. It's calling the completion
>> function straight from the IRQ handler, which is triggering the
>> sanity check in skcipher_walk_first.
>>
>> The s5p driver needs to schedule a tasklet to call the completion
>> function.
>
> Tasklet... or threaded IRQ handler maybe? I sent a fix.
>
> BTW, I subscribe the crypto list but I could not find the original email
> there.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt
From: Gilad Ben-Yossef @ 2017-03-06 14:38 UTC (permalink / raw)
To: Milan Broz
Cc: Binoy Jayan, Rajendra, Herbert Xu, Oded, Mike Snitzer,
Linux kernel mailing list, Ondrej Mosnacek, linux-raid, dm-devel,
Mark Brown, Arnd Bergmann, linux-crypto, Shaohua Li,
David S. Miller, Alasdair Kergon, Ofir
In-Reply-To: <c835926e-c2bd-8a52-34db-6c605301bc2b@gmail.com>
On Wed, Mar 1, 2017 at 5:38 PM, Milan Broz <gmazyland@gmail.com> 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
^ permalink raw reply
* Re: [PATCH v2 0/2] Propagate fallback bit for cbc and ctr
From: Marcelo Cerri @ 2017-03-06 12:20 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto, linux-kernel
In-Reply-To: <1488199106-16061-1-git-send-email-marcelo.cerri@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* [PATCH v6 2/4] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
From: Anup Patel @ 2017-03-06 9:43 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar
Cc: Dan Williams, Ray Jui, Scott Branden, Jon Mason, Rob Rice,
bcm-kernel-feedback-list, dmaengine, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, linux-raid, Anup Patel
In-Reply-To: <1488793408-25592-1-git-send-email-anup.patel@broadcom.com>
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 <anup.patel@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
---
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
^ permalink raw reply related
* [PATCH v6 1/4] lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position
From: Anup Patel @ 2017-03-06 9:43 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar
Cc: Dan Williams, Ray Jui, Scott Branden, Jon Mason, Rob Rice,
bcm-kernel-feedback-list, dmaengine, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, linux-raid, Anup Patel
In-Reply-To: <1488793408-25592-1-git-send-email-anup.patel@broadcom.com>
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 <anup.patel@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
---
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
^ permalink raw reply related
* [PATCH v6 4/4] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver
From: Anup Patel @ 2017-03-06 9:43 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar
Cc: Dan Williams, Ray Jui, Scott Branden, Jon Mason, Rob Rice,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA, Anup Patel
In-Reply-To: <1488793408-25592-1-git-send-email-anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
This patch adds the DT bindings document for newly added Broadcom
SBA RAID driver.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
.../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 0000000..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@67400000 {
+ ...
+ #mbox-cells = <3>;
+ ...
+};
+
+raid0 {
+ compatible = "brcm,iproc-sba-v2";
+ mboxes = <&raid_mbox 0 0x1 0xffff>,
+ <&raid_mbox 1 0x1 0xffff>,
+ <&raid_mbox 2 0x1 0xffff>,
+ <&raid_mbox 3 0x1 0xffff>,
+ <&raid_mbox 4 0x1 0xffff>,
+ <&raid_mbox 5 0x1 0xffff>,
+ <&raid_mbox 6 0x1 0xffff>,
+ <&raid_mbox 7 0x1 0xffff>;
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v6 3/4] dmaengine: Add Broadcom SBA RAID driver
From: Anup Patel @ 2017-03-06 9:43 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar
Cc: Dan Williams, Ray Jui, Scott Branden, Jon Mason, Rob Rice,
bcm-kernel-feedback-list, dmaengine, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, linux-raid, Anup Patel
In-Reply-To: <1488793408-25592-1-git-send-email-anup.patel@broadcom.com>
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 <anup.patel@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
---
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 0000000..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 <linux/bitops.h>
+#include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
+#include <linux/list.h>
+#include <linux/mailbox_client.h>
+#include <linux/mailbox/brcm-message.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/slab.h>
+#include <linux/raid/pq.h>
+
+#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 18
+#define SBA_C_MDATA_MS_MASK GENMASK(1, 0)
+#define SBA_INT_SHIFT 17
+#define SBA_INT_MASK BIT(0)
+#define SBA_RESP_SHIFT 16
+#define SBA_RESP_MASK BIT(0)
+#define SBA_C_MDATA_SHIFT 8
+#define SBA_C_MDATA_MASK GENMASK(7, 0)
+#define SBA_C_MDATA_BNUMx_SHIFT(__bnum) (2 * (__bnum))
+#define SBA_C_MDATA_BNUMx_MASK GENMASK(1, 0)
+#define SBA_C_MDATA_DNUM_SHIFT 5
+#define SBA_C_MDATA_DNUM_MASK GENMASK(4, 0)
+#define SBA_C_MDATA_LS(__v) ((__v) & 0xff)
+#define SBA_C_MDATA_MS(__v) (((__v) >> 8) & 0x3)
+#define SBA_CMD_SHIFT 0
+#define SBA_CMD_MASK GENMASK(3, 0)
+#define SBA_CMD_ZERO_BUFFER 0x4
+#define SBA_CMD_ZERO_ALL_BUFFERS 0x8
+#define SBA_CMD_LOAD_BUFFER 0x9
+#define SBA_CMD_XOR 0xa
+#define SBA_CMD_GALOIS_XOR 0xb
+#define SBA_CMD_WRITE_BUFFER 0xc
+#define SBA_CMD_GALOIS 0xe
+
+/* Driver helper macros */
+#define to_sba_request(tx) \
+ container_of(tx, struct sba_request, tx)
+#define to_sba_device(dchan) \
+ container_of(dchan, struct sba_device, dma_chan)
+
+enum sba_request_state {
+ SBA_REQUEST_STATE_FREE = 1,
+ SBA_REQUEST_STATE_ALLOCED = 2,
+ SBA_REQUEST_STATE_PENDING = 3,
+ SBA_REQUEST_STATE_ACTIVE = 4,
+ SBA_REQUEST_STATE_RECEIVED = 5,
+ SBA_REQUEST_STATE_COMPLETED = 6,
+ SBA_REQUEST_STATE_ABORTED = 7,
+};
+
+struct sba_request {
+ /* Global state */
+ struct list_head node;
+ struct sba_device *sba;
+ enum sba_request_state state;
+ bool fence;
+ /* Chained requests management */
+ struct sba_request *first;
+ struct list_head next;
+ unsigned int next_count;
+ atomic_t next_pending_count;
+ /* BRCM message data */
+ void *resp;
+ dma_addr_t resp_dma;
+ struct brcm_sba_command *cmds;
+ struct brcm_message msg;
+ struct dma_async_tx_descriptor tx;
+};
+
+enum sba_version {
+ SBA_VER_1 = 0,
+ SBA_VER_2
+};
+
+struct sba_device {
+ /* Underlying device */
+ struct device *dev;
+ /* DT configuration parameters */
+ enum sba_version ver;
+ /* Derived configuration parameters */
+ u32 max_req;
+ u32 hw_buf_size;
+ u32 hw_resp_size;
+ u32 max_pq_coefs;
+ u32 max_pq_srcs;
+ u32 max_cmd_per_req;
+ u32 max_xor_srcs;
+ u32 max_resp_pool_size;
+ u32 max_cmds_pool_size;
+ /* Maibox client and Mailbox channels */
+ struct mbox_client client;
+ int mchans_count;
+ atomic_t mchans_current;
+ struct mbox_chan **mchans;
+ struct device *mbox_dev;
+ /* DMA device and DMA channel */
+ struct dma_device dma_dev;
+ struct dma_chan dma_chan;
+ /* DMA channel resources */
+ void *resp_base;
+ dma_addr_t resp_dma_base;
+ void *cmds_base;
+ dma_addr_t cmds_dma_base;
+ spinlock_t reqs_lock;
+ struct sba_request *reqs;
+ bool reqs_fence;
+ struct list_head reqs_alloc_list;
+ struct list_head reqs_pending_list;
+ struct list_head reqs_active_list;
+ struct list_head reqs_received_list;
+ struct list_head reqs_completed_list;
+ struct list_head reqs_aborted_list;
+ struct list_head reqs_free_list;
+ int reqs_free_count;
+};
+
+/* ====== SBA command helper routines ===== */
+
+static inline u64 __pure sba_cmd_enc(u64 cmd, u32 val, u32 shift, u32 mask)
+{
+ cmd &= ~((u64)mask << shift);
+ cmd |= ((u64)(val & mask) << shift);
+ return cmd;
+}
+
+static inline u32 __pure sba_cmd_load_c_mdata(u32 b0)
+{
+ return b0 & SBA_C_MDATA_BNUMx_MASK;
+}
+
+static inline u32 __pure sba_cmd_write_c_mdata(u32 b0)
+{
+ return b0 & SBA_C_MDATA_BNUMx_MASK;
+}
+
+static inline u32 __pure sba_cmd_xor_c_mdata(u32 b1, u32 b0)
+{
+ return (b0 & SBA_C_MDATA_BNUMx_MASK) |
+ ((b1 & SBA_C_MDATA_BNUMx_MASK) << SBA_C_MDATA_BNUMx_SHIFT(1));
+}
+
+static inline u32 __pure sba_cmd_pq_c_mdata(u32 d, u32 b1, u32 b0)
+{
+ return (b0 & SBA_C_MDATA_BNUMx_MASK) |
+ ((b1 & SBA_C_MDATA_BNUMx_MASK) << SBA_C_MDATA_BNUMx_SHIFT(1)) |
+ ((d & SBA_C_MDATA_DNUM_MASK) << SBA_C_MDATA_DNUM_SHIFT);
+}
+
+/* ====== Channel resource management routines ===== */
+
+static struct sba_request *sba_alloc_request(struct sba_device *sba)
+{
+ unsigned long flags;
+ struct sba_request *req = NULL;
+
+ spin_lock_irqsave(&sba->reqs_lock, flags);
+
+ req = list_first_entry_or_null(&sba->reqs_free_list,
+ struct sba_request, node);
+ if (req) {
+ list_move_tail(&req->node, &sba->reqs_alloc_list);
+ req->state = SBA_REQUEST_STATE_ALLOCED;
+ req->fence = false;
+ req->first = req;
+ INIT_LIST_HEAD(&req->next);
+ req->next_count = 1;
+ atomic_set(&req->next_pending_count, 1);
+
+ sba->reqs_free_count--;
+
+ dma_async_tx_descriptor_init(&req->tx, &sba->dma_chan);
+ }
+
+ spin_unlock_irqrestore(&sba->reqs_lock, flags);
+
+ return req;
+}
+
+/* Note: Must be called with sba->reqs_lock held */
+static void _sba_pending_request(struct sba_device *sba,
+ struct sba_request *req)
+{
+ lockdep_assert_held(&sba->reqs_lock);
+ req->state = SBA_REQUEST_STATE_PENDING;
+ list_move_tail(&req->node, &sba->reqs_pending_list);
+ if (list_empty(&sba->reqs_active_list))
+ sba->reqs_fence = false;
+}
+
+/* Note: Must be called with sba->reqs_lock held */
+static bool _sba_active_request(struct sba_device *sba,
+ struct sba_request *req)
+{
+ lockdep_assert_held(&sba->reqs_lock);
+ if (list_empty(&sba->reqs_active_list))
+ sba->reqs_fence = false;
+ if (sba->reqs_fence)
+ return false;
+ req->state = SBA_REQUEST_STATE_ACTIVE;
+ list_move_tail(&req->node, &sba->reqs_active_list);
+ if (req->fence)
+ sba->reqs_fence = true;
+ return true;
+}
+
+/* Note: Must be called with sba->reqs_lock held */
+static void _sba_abort_request(struct sba_device *sba,
+ struct sba_request *req)
+{
+ lockdep_assert_held(&sba->reqs_lock);
+ req->state = SBA_REQUEST_STATE_ABORTED;
+ list_move_tail(&req->node, &sba->reqs_aborted_list);
+ if (list_empty(&sba->reqs_active_list))
+ sba->reqs_fence = false;
+}
+
+/* Note: Must be called with sba->reqs_lock held */
+static void _sba_free_request(struct sba_device *sba,
+ struct sba_request *req)
+{
+ lockdep_assert_held(&sba->reqs_lock);
+ req->state = SBA_REQUEST_STATE_FREE;
+ list_move_tail(&req->node, &sba->reqs_free_list);
+ if (list_empty(&sba->reqs_active_list))
+ sba->reqs_fence = false;
+ sba->reqs_free_count++;
+}
+
+static void sba_received_request(struct sba_request *req)
+{
+ unsigned long flags;
+ struct sba_device *sba = req->sba;
+
+ spin_lock_irqsave(&sba->reqs_lock, flags);
+ req->state = SBA_REQUEST_STATE_RECEIVED;
+ list_move_tail(&req->node, &sba->reqs_received_list);
+ spin_unlock_irqrestore(&sba->reqs_lock, flags);
+}
+
+static void sba_complete_chained_requests(struct sba_request *req)
+{
+ unsigned long flags;
+ struct sba_request *nreq;
+ struct sba_device *sba = req->sba;
+
+ spin_lock_irqsave(&sba->reqs_lock, flags);
+
+ req->state = SBA_REQUEST_STATE_COMPLETED;
+ list_move_tail(&req->node, &sba->reqs_completed_list);
+ list_for_each_entry(nreq, &req->next, next) {
+ nreq->state = SBA_REQUEST_STATE_COMPLETED;
+ list_move_tail(&nreq->node, &sba->reqs_completed_list);
+ }
+ if (list_empty(&sba->reqs_active_list))
+ sba->reqs_fence = false;
+
+ spin_unlock_irqrestore(&sba->reqs_lock, flags);
+}
+
+static void sba_free_chained_requests(struct sba_request *req)
+{
+ unsigned long flags;
+ struct sba_request *nreq;
+ struct sba_device *sba = req->sba;
+
+ spin_lock_irqsave(&sba->reqs_lock, flags);
+
+ _sba_free_request(sba, req);
+ list_for_each_entry(nreq, &req->next, next)
+ _sba_free_request(sba, nreq);
+
+ spin_unlock_irqrestore(&sba->reqs_lock, flags);
+}
+
+static void sba_chain_request(struct sba_request *first,
+ struct sba_request *req)
+{
+ unsigned long flags;
+ struct sba_device *sba = req->sba;
+
+ spin_lock_irqsave(&sba->reqs_lock, flags);
+
+ list_add_tail(&req->next, &first->next);
+ req->first = first;
+ first->next_count++;
+ atomic_set(&first->next_pending_count, first->next_count);
+
+ spin_unlock_irqrestore(&sba->reqs_lock, flags);
+}
+
+static void sba_cleanup_nonpending_requests(struct sba_device *sba)
+{
+ unsigned long flags;
+ struct sba_request *req, *req1;
+
+ spin_lock_irqsave(&sba->reqs_lock, flags);
+
+ /* Freeup all alloced request */
+ list_for_each_entry_safe(req, req1, &sba->reqs_alloc_list, node)
+ _sba_free_request(sba, req);
+
+ /* Freeup all received request */
+ list_for_each_entry_safe(req, req1, &sba->reqs_received_list, node)
+ _sba_free_request(sba, req);
+
+ /* Freeup all completed request */
+ list_for_each_entry_safe(req, req1, &sba->reqs_completed_list, node)
+ _sba_free_request(sba, req);
+
+ /* Set all active requests as aborted */
+ list_for_each_entry_safe(req, req1, &sba->reqs_active_list, node)
+ _sba_abort_request(sba, req);
+
+ /*
+ * Note: We expect that aborted request will be eventually
+ * freed by sba_receive_message()
+ */
+
+ spin_unlock_irqrestore(&sba->reqs_lock, flags);
+}
+
+static void sba_cleanup_pending_requests(struct sba_device *sba)
+{
+ unsigned long flags;
+ struct sba_request *req, *req1;
+
+ spin_lock_irqsave(&sba->reqs_lock, flags);
+
+ /* Freeup all pending request */
+ list_for_each_entry_safe(req, req1, &sba->reqs_pending_list, node)
+ _sba_free_request(sba, req);
+
+ spin_unlock_irqrestore(&sba->reqs_lock, flags);
+}
+
+/* ====== DMAENGINE callbacks ===== */
+
+static void sba_free_chan_resources(struct dma_chan *dchan)
+{
+ /*
+ * Channel resources are pre-alloced so we just free-up
+ * whatever we can so that we can re-use pre-alloced
+ * channel resources next time.
+ */
+ sba_cleanup_nonpending_requests(to_sba_device(dchan));
+}
+
+static int sba_device_terminate_all(struct dma_chan *dchan)
+{
+ /* Cleanup all pending requests */
+ sba_cleanup_pending_requests(to_sba_device(dchan));
+
+ return 0;
+}
+
+static int sba_send_mbox_request(struct sba_device *sba,
+ struct sba_request *req)
+{
+ int mchans_idx, ret = 0;
+
+ /* Select mailbox channel in round-robin fashion */
+ mchans_idx = atomic_inc_return(&sba->mchans_current);
+ mchans_idx = mchans_idx % sba->mchans_count;
+
+ /* Send message for the request */
+ req->msg.error = 0;
+ ret = mbox_send_message(sba->mchans[mchans_idx], &req->msg);
+ if (ret < 0) {
+ dev_err(sba->dev, "send message failed with error %d", ret);
+ return ret;
+ }
+ ret = req->msg.error;
+ if (ret < 0) {
+ dev_err(sba->dev, "message error %d", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void sba_issue_pending(struct dma_chan *dchan)
+{
+ int ret;
+ unsigned long flags;
+ struct sba_request *req, *req1;
+ struct sba_device *sba = to_sba_device(dchan);
+
+ spin_lock_irqsave(&sba->reqs_lock, flags);
+
+ /* Process all pending request */
+ list_for_each_entry_safe(req, req1, &sba->reqs_pending_list, node) {
+ /* Try to make request active */
+ if (!_sba_active_request(sba, req))
+ break;
+
+ /* Send request to mailbox channel */
+ spin_unlock_irqrestore(&sba->reqs_lock, flags);
+ ret = sba_send_mbox_request(sba, req);
+ spin_lock_irqsave(&sba->reqs_lock, flags);
+
+ /* If something went wrong then keep request pending */
+ if (ret < 0) {
+ _sba_pending_request(sba, req);
+ break;
+ }
+ }
+
+ spin_unlock_irqrestore(&sba->reqs_lock, flags);
+}
+
+static dma_cookie_t sba_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+ unsigned long flags;
+ dma_cookie_t cookie;
+ struct sba_device *sba;
+ struct sba_request *req, *nreq;
+
+ if (unlikely(!tx))
+ return -EINVAL;
+
+ sba = to_sba_device(tx->chan);
+ req = to_sba_request(tx);
+
+ /* Assign cookie and mark all chained requests pending */
+ spin_lock_irqsave(&sba->reqs_lock, flags);
+ cookie = dma_cookie_assign(tx);
+ _sba_pending_request(sba, req);
+ list_for_each_entry(nreq, &req->next, next)
+ _sba_pending_request(sba, nreq);
+ spin_unlock_irqrestore(&sba->reqs_lock, flags);
+
+ return cookie;
+}
+
+static enum dma_status sba_tx_status(struct dma_chan *dchan,
+ dma_cookie_t cookie,
+ struct dma_tx_state *txstate)
+{
+ int mchan_idx;
+ enum dma_status ret;
+ struct sba_device *sba = to_sba_device(dchan);
+
+ for (mchan_idx = 0; mchan_idx < sba->mchans_count; mchan_idx++)
+ mbox_client_peek_data(sba->mchans[mchan_idx]);
+
+ ret = dma_cookie_status(dchan, cookie, txstate);
+ if (ret == DMA_COMPLETE)
+ return ret;
+
+ return dma_cookie_status(dchan, cookie, txstate);
+}
+
+static void sba_fillup_interrupt_msg(struct sba_request *req,
+ struct brcm_sba_command *cmds,
+ struct brcm_message *msg)
+{
+ u64 cmd;
+ u32 c_mdata;
+ struct brcm_sba_command *cmdsp = cmds;
+
+ /* Type-B command to load dummy data into buf0 */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_B,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, req->sba->hw_resp_size,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_load_c_mdata(0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_LOAD_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_B;
+ cmdsp->data = req->resp_dma;
+ cmdsp->data_len = req->sba->hw_resp_size;
+ cmdsp++;
+
+ /* Type-A command to write buf0 to dummy location */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_A,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, req->sba->hw_resp_size,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ cmd = sba_cmd_enc(cmd, 0x1,
+ SBA_RESP_SHIFT, SBA_RESP_MASK);
+ c_mdata = sba_cmd_write_c_mdata(0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_WRITE_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_A;
+ if (req->sba->hw_resp_size) {
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_RESP;
+ cmdsp->resp = req->resp_dma;
+ cmdsp->resp_len = req->sba->hw_resp_size;
+ }
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_OUTPUT;
+ cmdsp->data = req->resp_dma;
+ cmdsp->data_len = req->sba->hw_resp_size;
+ cmdsp++;
+
+ /* Fillup brcm_message */
+ msg->type = BRCM_MESSAGE_SBA;
+ msg->sba.cmds = cmds;
+ msg->sba.cmds_count = cmdsp - cmds;
+ msg->ctx = req;
+ msg->error = 0;
+}
+
+static struct dma_async_tx_descriptor *
+sba_prep_dma_interrupt(struct dma_chan *dchan, unsigned long flags)
+{
+ struct sba_request *req = NULL;
+ struct sba_device *sba = to_sba_device(dchan);
+
+ /* Alloc new request */
+ req = sba_alloc_request(sba);
+ if (!req)
+ return NULL;
+
+ /*
+ * Force fence so that no requests are submitted
+ * until DMA callback for this request is invoked.
+ */
+ req->fence = true;
+
+ /* Fillup request message */
+ sba_fillup_interrupt_msg(req, req->cmds, &req->msg);
+
+ /* Init async_tx descriptor */
+ req->tx.flags = flags;
+ req->tx.cookie = -EBUSY;
+
+ return (req) ? &req->tx : NULL;
+}
+
+static void sba_fillup_memcpy_msg(struct sba_request *req,
+ struct brcm_sba_command *cmds,
+ struct brcm_message *msg,
+ dma_addr_t msg_offset, size_t msg_len,
+ dma_addr_t dst, dma_addr_t src)
+{
+ u64 cmd;
+ u32 c_mdata;
+ struct brcm_sba_command *cmdsp = cmds;
+
+ /* Type-B command to load data into buf0 */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_B,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_load_c_mdata(0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_LOAD_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_B;
+ cmdsp->data = src + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+
+ /* Type-A command to write buf0 */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_A,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ cmd = sba_cmd_enc(cmd, 0x1,
+ SBA_RESP_SHIFT, SBA_RESP_MASK);
+ c_mdata = sba_cmd_write_c_mdata(0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_WRITE_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_A;
+ if (req->sba->hw_resp_size) {
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_RESP;
+ cmdsp->resp = req->resp_dma;
+ cmdsp->resp_len = req->sba->hw_resp_size;
+ }
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_OUTPUT;
+ cmdsp->data = dst + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+
+ /* Fillup brcm_message */
+ msg->type = BRCM_MESSAGE_SBA;
+ msg->sba.cmds = cmds;
+ msg->sba.cmds_count = cmdsp - cmds;
+ msg->ctx = req;
+ msg->error = 0;
+}
+
+static struct sba_request *
+sba_prep_dma_memcpy_req(struct sba_device *sba,
+ dma_addr_t off, dma_addr_t dst, dma_addr_t src,
+ size_t len, unsigned long flags)
+{
+ struct sba_request *req = NULL;
+
+ /* Alloc new request */
+ req = sba_alloc_request(sba);
+ if (!req)
+ return NULL;
+ req->fence = (flags & DMA_PREP_FENCE) ? true : false;
+
+ /* Fillup request message */
+ sba_fillup_memcpy_msg(req, req->cmds, &req->msg,
+ off, len, dst, src);
+
+ /* Init async_tx descriptor */
+ req->tx.flags = flags;
+ req->tx.cookie = -EBUSY;
+
+ return req;
+}
+
+static struct dma_async_tx_descriptor *
+sba_prep_dma_memcpy(struct dma_chan *dchan, dma_addr_t dst, dma_addr_t src,
+ size_t len, unsigned long flags)
+{
+ size_t req_len;
+ dma_addr_t off = 0;
+ struct sba_device *sba = to_sba_device(dchan);
+ struct sba_request *first = NULL, *req;
+
+ /* Create chained requests where each request is upto hw_buf_size */
+ while (len) {
+ req_len = (len < sba->hw_buf_size) ? len : sba->hw_buf_size;
+
+ req = sba_prep_dma_memcpy_req(sba, off, dst, src,
+ req_len, flags);
+ if (!req) {
+ if (first)
+ sba_free_chained_requests(first);
+ return NULL;
+ }
+
+ if (first)
+ sba_chain_request(first, req);
+ else
+ first = req;
+
+ off += req_len;
+ len -= req_len;
+ }
+
+ return (first) ? &first->tx : NULL;
+}
+
+static void sba_fillup_xor_msg(struct sba_request *req,
+ struct brcm_sba_command *cmds,
+ struct brcm_message *msg,
+ dma_addr_t msg_offset, size_t msg_len,
+ dma_addr_t dst, dma_addr_t *src, u32 src_cnt)
+{
+ u64 cmd;
+ u32 c_mdata;
+ unsigned int i;
+ struct brcm_sba_command *cmdsp = cmds;
+
+ /* Type-B command to load data into buf0 */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_B,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_load_c_mdata(0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_LOAD_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_B;
+ cmdsp->data = src[0] + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+
+ /* Type-B commands to xor data with buf0 and put it back in buf0 */
+ for (i = 1; i < src_cnt; i++) {
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_B,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_xor_c_mdata(0, 0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_XOR,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_B;
+ cmdsp->data = src[i] + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+ }
+
+ /* Type-A command to write buf0 */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_A,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ cmd = sba_cmd_enc(cmd, 0x1,
+ SBA_RESP_SHIFT, SBA_RESP_MASK);
+ c_mdata = sba_cmd_write_c_mdata(0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_WRITE_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_A;
+ if (req->sba->hw_resp_size) {
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_RESP;
+ cmdsp->resp = req->resp_dma;
+ cmdsp->resp_len = req->sba->hw_resp_size;
+ }
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_OUTPUT;
+ cmdsp->data = dst + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+
+ /* Fillup brcm_message */
+ msg->type = BRCM_MESSAGE_SBA;
+ msg->sba.cmds = cmds;
+ msg->sba.cmds_count = cmdsp - cmds;
+ msg->ctx = req;
+ msg->error = 0;
+}
+
+struct sba_request *
+sba_prep_dma_xor_req(struct sba_device *sba,
+ dma_addr_t off, dma_addr_t dst, dma_addr_t *src,
+ u32 src_cnt, size_t len, unsigned long flags)
+{
+ struct sba_request *req = NULL;
+
+ /* Alloc new request */
+ req = sba_alloc_request(sba);
+ if (!req)
+ return NULL;
+ req->fence = (flags & DMA_PREP_FENCE) ? true : false;
+
+ /* Fillup request message */
+ sba_fillup_xor_msg(req, req->cmds, &req->msg,
+ off, len, dst, src, src_cnt);
+
+ /* Init async_tx descriptor */
+ req->tx.flags = flags;
+ req->tx.cookie = -EBUSY;
+
+ return req;
+}
+
+static struct dma_async_tx_descriptor *
+sba_prep_dma_xor(struct dma_chan *dchan, dma_addr_t dst, dma_addr_t *src,
+ u32 src_cnt, size_t len, unsigned long flags)
+{
+ size_t req_len;
+ dma_addr_t off = 0;
+ struct sba_device *sba = to_sba_device(dchan);
+ struct sba_request *first = NULL, *req;
+
+ /* Sanity checks */
+ if (unlikely(src_cnt > sba->max_xor_srcs))
+ return NULL;
+
+ /* Create chained requests where each request is upto hw_buf_size */
+ while (len) {
+ req_len = (len < sba->hw_buf_size) ? len : sba->hw_buf_size;
+
+ req = sba_prep_dma_xor_req(sba, off, dst, src, src_cnt,
+ req_len, flags);
+ if (!req) {
+ if (first)
+ sba_free_chained_requests(first);
+ return NULL;
+ }
+
+ if (first)
+ sba_chain_request(first, req);
+ else
+ first = req;
+
+ off += req_len;
+ len -= req_len;
+ }
+
+ return (first) ? &first->tx : NULL;
+}
+
+static void sba_fillup_pq_msg(struct sba_request *req,
+ bool pq_continue,
+ struct brcm_sba_command *cmds,
+ struct brcm_message *msg,
+ dma_addr_t msg_offset, size_t msg_len,
+ dma_addr_t *dst_p, dma_addr_t *dst_q,
+ const u8 *scf, dma_addr_t *src, u32 src_cnt)
+{
+ u64 cmd;
+ u32 c_mdata;
+ unsigned int i;
+ struct brcm_sba_command *cmdsp = cmds;
+
+ if (pq_continue) {
+ /* Type-B command to load old P into buf0 */
+ if (dst_p) {
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_B,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_load_c_mdata(0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_LOAD_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_B;
+ cmdsp->data = *dst_p + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+ }
+
+ /* Type-B command to load old Q into buf1 */
+ if (dst_q) {
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_B,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_load_c_mdata(1);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_LOAD_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_B;
+ cmdsp->data = *dst_q + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+ }
+ } else {
+ /* Type-A command to zero all buffers */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_A,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_ZERO_ALL_BUFFERS,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_A;
+ cmdsp++;
+ }
+
+ /* Type-B commands for generate P onto buf0 and Q onto buf1 */
+ for (i = 0; i < src_cnt; i++) {
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_B,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_pq_c_mdata(raid6_gflog[scf[i]], 1, 0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_MS(c_mdata),
+ SBA_C_MDATA_MS_SHIFT, SBA_C_MDATA_MS_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_GALOIS_XOR,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_B;
+ cmdsp->data = src[i] + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+ }
+
+ /* Type-A command to write buf0 */
+ if (dst_p) {
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_A,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ cmd = sba_cmd_enc(cmd, 0x1,
+ SBA_RESP_SHIFT, SBA_RESP_MASK);
+ c_mdata = sba_cmd_write_c_mdata(0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_WRITE_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_A;
+ if (req->sba->hw_resp_size) {
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_RESP;
+ cmdsp->resp = req->resp_dma;
+ cmdsp->resp_len = req->sba->hw_resp_size;
+ }
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_OUTPUT;
+ cmdsp->data = *dst_p + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+ }
+
+ /* Type-A command to write buf1 */
+ if (dst_q) {
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_A,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ cmd = sba_cmd_enc(cmd, 0x1,
+ SBA_RESP_SHIFT, SBA_RESP_MASK);
+ c_mdata = sba_cmd_write_c_mdata(1);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_WRITE_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_A;
+ if (req->sba->hw_resp_size) {
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_RESP;
+ cmdsp->resp = req->resp_dma;
+ cmdsp->resp_len = req->sba->hw_resp_size;
+ }
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_OUTPUT;
+ cmdsp->data = *dst_q + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+ }
+
+ /* Fillup brcm_message */
+ msg->type = BRCM_MESSAGE_SBA;
+ msg->sba.cmds = cmds;
+ msg->sba.cmds_count = cmdsp - cmds;
+ msg->ctx = req;
+ msg->error = 0;
+}
+
+struct sba_request *
+sba_prep_dma_pq_req(struct sba_device *sba, dma_addr_t off,
+ dma_addr_t *dst_p, dma_addr_t *dst_q, dma_addr_t *src,
+ u32 src_cnt, const u8 *scf, size_t len, unsigned long flags)
+{
+ struct sba_request *req = NULL;
+
+ /* Alloc new request */
+ req = sba_alloc_request(sba);
+ if (!req)
+ return NULL;
+ req->fence = (flags & DMA_PREP_FENCE) ? true : false;
+
+ /* Fillup request messages */
+ sba_fillup_pq_msg(req, dmaf_continue(flags),
+ req->cmds, &req->msg,
+ off, len, dst_p, dst_q, scf, src, src_cnt);
+
+ /* Init async_tx descriptor */
+ req->tx.flags = flags;
+ req->tx.cookie = -EBUSY;
+
+ return req;
+}
+
+static void sba_fillup_pq_single_msg(struct sba_request *req,
+ bool pq_continue,
+ struct brcm_sba_command *cmds,
+ struct brcm_message *msg,
+ dma_addr_t msg_offset, size_t msg_len,
+ dma_addr_t *dst_p, dma_addr_t *dst_q,
+ dma_addr_t src, u8 scf)
+{
+ u64 cmd;
+ u32 c_mdata;
+ u8 pos, dpos = raid6_gflog[scf];
+ struct brcm_sba_command *cmdsp = cmds;
+
+ if (!dst_p)
+ goto skip_p;
+
+ if (pq_continue) {
+ /* Type-B command to load old P into buf0 */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_B,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_load_c_mdata(0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_LOAD_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_B;
+ cmdsp->data = *dst_p + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+
+ /*
+ * Type-B commands to xor data with buf0 and put it
+ * back in buf0
+ */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_B,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_xor_c_mdata(0, 0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_XOR,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_B;
+ cmdsp->data = src + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+ } else {
+ /* Type-B command to load old P into buf0 */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_B,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_load_c_mdata(0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_LOAD_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_B;
+ cmdsp->data = src + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+ }
+
+ /* Type-A command to write buf0 */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_A,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ cmd = sba_cmd_enc(cmd, 0x1,
+ SBA_RESP_SHIFT, SBA_RESP_MASK);
+ c_mdata = sba_cmd_write_c_mdata(0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_WRITE_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_A;
+ if (req->sba->hw_resp_size) {
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_RESP;
+ cmdsp->resp = req->resp_dma;
+ cmdsp->resp_len = req->sba->hw_resp_size;
+ }
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_OUTPUT;
+ cmdsp->data = *dst_p + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+
+skip_p:
+ if (!dst_q)
+ goto skip_q;
+
+ /* Type-A command to zero all buffers */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_A,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_ZERO_ALL_BUFFERS,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_A;
+ cmdsp++;
+
+ if (dpos == 255)
+ goto skip_q_computation;
+ pos = (dpos < req->sba->max_pq_coefs) ?
+ dpos : (req->sba->max_pq_coefs - 1);
+
+ /*
+ * Type-B command to generate initial Q from data
+ * and store output into buf0
+ */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_B,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_pq_c_mdata(pos, 0, 0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_MS(c_mdata),
+ SBA_C_MDATA_MS_SHIFT, SBA_C_MDATA_MS_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_GALOIS,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_B;
+ cmdsp->data = src + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+
+ dpos -= pos;
+
+ /* Multiple Type-A command to generate final Q */
+ while (dpos) {
+ pos = (dpos < req->sba->max_pq_coefs) ?
+ dpos : (req->sba->max_pq_coefs - 1);
+
+ /*
+ * Type-A command to generate Q with buf0 and
+ * buf1 store result in buf0
+ */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_A,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_pq_c_mdata(pos, 0, 1);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_MS(c_mdata),
+ SBA_C_MDATA_MS_SHIFT, SBA_C_MDATA_MS_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_GALOIS,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_A;
+ cmdsp++;
+
+ dpos -= pos;
+ }
+
+skip_q_computation:
+ if (pq_continue) {
+ /*
+ * Type-B command to XOR previous output with
+ * buf0 and write it into buf0
+ */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_B,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ c_mdata = sba_cmd_xor_c_mdata(0, 0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_XOR,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_B;
+ cmdsp->data = *dst_q + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+ }
+
+ /* Type-A command to write buf0 */
+ cmd = sba_cmd_enc(0x0, SBA_TYPE_A,
+ SBA_TYPE_SHIFT, SBA_TYPE_MASK);
+ cmd = sba_cmd_enc(cmd, msg_len,
+ SBA_USER_DEF_SHIFT, SBA_USER_DEF_MASK);
+ cmd = sba_cmd_enc(cmd, 0x1,
+ SBA_RESP_SHIFT, SBA_RESP_MASK);
+ c_mdata = sba_cmd_write_c_mdata(0);
+ cmd = sba_cmd_enc(cmd, SBA_C_MDATA_LS(c_mdata),
+ SBA_C_MDATA_SHIFT, SBA_C_MDATA_MASK);
+ cmd = sba_cmd_enc(cmd, SBA_CMD_WRITE_BUFFER,
+ SBA_CMD_SHIFT, SBA_CMD_MASK);
+ cmdsp->cmd = cmd;
+ *cmdsp->cmd_dma = cpu_to_le64(cmd);
+ cmdsp->flags = BRCM_SBA_CMD_TYPE_A;
+ if (req->sba->hw_resp_size) {
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_RESP;
+ cmdsp->resp = req->resp_dma;
+ cmdsp->resp_len = req->sba->hw_resp_size;
+ }
+ cmdsp->flags |= BRCM_SBA_CMD_HAS_OUTPUT;
+ cmdsp->data = *dst_q + msg_offset;
+ cmdsp->data_len = msg_len;
+ cmdsp++;
+
+skip_q:
+ /* Fillup brcm_message */
+ msg->type = BRCM_MESSAGE_SBA;
+ msg->sba.cmds = cmds;
+ msg->sba.cmds_count = cmdsp - cmds;
+ msg->ctx = req;
+ msg->error = 0;
+}
+
+struct sba_request *
+sba_prep_dma_pq_single_req(struct sba_device *sba, dma_addr_t off,
+ dma_addr_t *dst_p, dma_addr_t *dst_q,
+ dma_addr_t src, u8 scf, size_t len,
+ unsigned long flags)
+{
+ struct sba_request *req = NULL;
+
+ /* Alloc new request */
+ req = sba_alloc_request(sba);
+ if (!req)
+ return NULL;
+ req->fence = (flags & DMA_PREP_FENCE) ? true : false;
+
+ /* Fillup request messages */
+ sba_fillup_pq_single_msg(req, dmaf_continue(flags),
+ req->cmds, &req->msg, off, len,
+ dst_p, dst_q, src, scf);
+
+ /* Init async_tx descriptor */
+ req->tx.flags = flags;
+ req->tx.cookie = -EBUSY;
+
+ return req;
+}
+
+static struct dma_async_tx_descriptor *
+sba_prep_dma_pq(struct dma_chan *dchan, dma_addr_t *dst, dma_addr_t *src,
+ u32 src_cnt, const u8 *scf, size_t len, unsigned long flags)
+{
+ u32 i, dst_q_index;
+ size_t req_len;
+ bool slow = false;
+ dma_addr_t off = 0;
+ dma_addr_t *dst_p = NULL, *dst_q = NULL;
+ struct sba_device *sba = to_sba_device(dchan);
+ struct sba_request *first = NULL, *req;
+
+ /* Sanity checks */
+ if (unlikely(src_cnt > sba->max_pq_srcs))
+ return NULL;
+ for (i = 0; i < src_cnt; i++)
+ if (sba->max_pq_coefs <= raid6_gflog[scf[i]])
+ slow = true;
+
+ /* Figure-out P and Q destination addresses */
+ if (!(flags & DMA_PREP_PQ_DISABLE_P))
+ dst_p = &dst[0];
+ if (!(flags & DMA_PREP_PQ_DISABLE_Q))
+ dst_q = &dst[1];
+
+ /* Create chained requests where each request is upto hw_buf_size */
+ while (len) {
+ req_len = (len < sba->hw_buf_size) ? len : sba->hw_buf_size;
+
+ if (slow) {
+ dst_q_index = src_cnt;
+
+ if (dst_q) {
+ for (i = 0; i < src_cnt; i++) {
+ if (*dst_q == src[i]) {
+ dst_q_index = i;
+ break;
+ }
+ }
+ }
+
+ if (dst_q_index < src_cnt) {
+ i = dst_q_index;
+ req = sba_prep_dma_pq_single_req(sba,
+ off, dst_p, dst_q, src[i], scf[i],
+ req_len, flags | DMA_PREP_FENCE);
+ if (!req)
+ goto fail;
+
+ if (first)
+ sba_chain_request(first, req);
+ else
+ first = req;
+
+ flags |= DMA_PREP_CONTINUE;
+ }
+
+ for (i = 0; i < src_cnt; i++) {
+ if (dst_q_index == i)
+ continue;
+
+ req = sba_prep_dma_pq_single_req(sba,
+ off, dst_p, dst_q, src[i], scf[i],
+ req_len, flags | DMA_PREP_FENCE);
+ if (!req)
+ goto fail;
+
+ if (first)
+ sba_chain_request(first, req);
+ else
+ first = req;
+
+ flags |= DMA_PREP_CONTINUE;
+ }
+ } else {
+ req = sba_prep_dma_pq_req(sba, off,
+ dst_p, dst_q, src, src_cnt,
+ scf, req_len, flags);
+ if (!req)
+ goto fail;
+
+ if (first)
+ sba_chain_request(first, req);
+ else
+ first = req;
+ }
+
+ off += req_len;
+ len -= req_len;
+ }
+
+ return (first) ? &first->tx : NULL;
+
+fail:
+ if (first)
+ sba_free_chained_requests(first);
+ return NULL;
+}
+
+/* ====== Mailbox callbacks ===== */
+
+static void sba_dma_tx_actions(struct sba_request *req)
+{
+ struct dma_async_tx_descriptor *tx = &req->tx;
+
+ WARN_ON(tx->cookie < 0);
+
+ if (tx->cookie > 0) {
+ dma_cookie_complete(tx);
+
+ /*
+ * Call the callback (must not sleep or submit new
+ * operations to this channel)
+ */
+ if (tx->callback)
+ tx->callback(tx->callback_param);
+
+ dma_descriptor_unmap(tx);
+ }
+
+ /* Run dependent operations */
+ dma_run_dependencies(tx);
+
+ /* If waiting for 'ack' then move to completed list */
+ if (!async_tx_test_ack(&req->tx))
+ sba_complete_chained_requests(req);
+ else
+ sba_free_chained_requests(req);
+}
+
+static void sba_receive_message(struct mbox_client *cl, void *msg)
+{
+ unsigned long flags;
+ struct brcm_message *m = msg;
+ struct sba_request *req = m->ctx, *req1;
+ struct sba_device *sba = req->sba;
+
+ /* Error count if message has error */
+ if (m->error < 0)
+ dev_err(sba->dev, "%s got message with error %d",
+ dma_chan_name(&sba->dma_chan), m->error);
+
+ /* Mark request as received */
+ sba_received_request(req);
+
+ /* Wait for all chained requests to be completed */
+ if (atomic_dec_return(&req->first->next_pending_count))
+ goto done;
+
+ /* Point to first request */
+ req = req->first;
+
+ /* Update request */
+ if (req->state == SBA_REQUEST_STATE_RECEIVED)
+ sba_dma_tx_actions(req);
+ else
+ sba_free_chained_requests(req);
+
+ spin_lock_irqsave(&sba->reqs_lock, flags);
+
+ /* Re-check all completed request waiting for 'ack' */
+ list_for_each_entry_safe(req, req1, &sba->reqs_completed_list, node) {
+ spin_unlock_irqrestore(&sba->reqs_lock, flags);
+ sba_dma_tx_actions(req);
+ spin_lock_irqsave(&sba->reqs_lock, flags);
+ }
+
+ spin_unlock_irqrestore(&sba->reqs_lock, flags);
+
+done:
+ /* Try to submit pending request */
+ sba_issue_pending(&sba->dma_chan);
+}
+
+/* ====== Platform driver routines ===== */
+
+static int sba_prealloc_channel_resources(struct sba_device *sba)
+{
+ int i, j, p, ret = 0;
+ struct sba_request *req = NULL;
+
+ sba->resp_base = dma_alloc_coherent(sba->dma_dev.dev,
+ sba->max_resp_pool_size,
+ &sba->resp_dma_base, GFP_KERNEL);
+ if (!sba->resp_base)
+ return -ENOMEM;
+
+ sba->cmds_base = dma_alloc_coherent(sba->dma_dev.dev,
+ sba->max_cmds_pool_size,
+ &sba->cmds_dma_base, GFP_KERNEL);
+ if (!sba->cmds_base) {
+ ret = -ENOMEM;
+ goto fail_free_resp_pool;
+ }
+
+ spin_lock_init(&sba->reqs_lock);
+ sba->reqs_fence = false;
+ INIT_LIST_HEAD(&sba->reqs_alloc_list);
+ INIT_LIST_HEAD(&sba->reqs_pending_list);
+ INIT_LIST_HEAD(&sba->reqs_active_list);
+ INIT_LIST_HEAD(&sba->reqs_received_list);
+ INIT_LIST_HEAD(&sba->reqs_completed_list);
+ INIT_LIST_HEAD(&sba->reqs_aborted_list);
+ INIT_LIST_HEAD(&sba->reqs_free_list);
+
+ sba->reqs = devm_kcalloc(sba->dev, sba->max_req,
+ sizeof(*req), GFP_KERNEL);
+ if (!sba->reqs) {
+ ret = -ENOMEM;
+ goto fail_free_cmds_pool;
+ }
+
+ for (i = 0, p = 0; i < sba->max_req; i++) {
+ req = &sba->reqs[i];
+ INIT_LIST_HEAD(&req->node);
+ req->sba = sba;
+ req->state = SBA_REQUEST_STATE_FREE;
+ INIT_LIST_HEAD(&req->next);
+ req->next_count = 1;
+ atomic_set(&req->next_pending_count, 0);
+ req->fence = false;
+ req->resp = sba->resp_base + p;
+ req->resp_dma = sba->resp_dma_base + p;
+ p += sba->hw_resp_size;
+ req->cmds = devm_kcalloc(sba->dev, sba->max_cmd_per_req,
+ sizeof(*req->cmds), GFP_KERNEL);
+ if (!req->cmds) {
+ ret = -ENOMEM;
+ goto fail_free_cmds_pool;
+ }
+ for (j = 0; j < sba->max_cmd_per_req; j++) {
+ req->cmds[j].cmd = 0;
+ req->cmds[j].cmd_dma = sba->cmds_base +
+ (i * sba->max_cmd_per_req + j) * sizeof(u64);
+ req->cmds[j].cmd_dma_addr = sba->cmds_dma_base +
+ (i * sba->max_cmd_per_req + j) * sizeof(u64);
+ req->cmds[j].flags = 0;
+ }
+ memset(&req->msg, 0, sizeof(req->msg));
+ dma_async_tx_descriptor_init(&req->tx, &sba->dma_chan);
+ req->tx.tx_submit = sba_tx_submit;
+ req->tx.phys = req->resp_dma;
+ list_add_tail(&req->node, &sba->reqs_free_list);
+ }
+
+ sba->reqs_free_count = sba->max_req;
+
+ return 0;
+
+fail_free_cmds_pool:
+ dma_free_coherent(sba->dma_dev.dev,
+ sba->max_cmds_pool_size,
+ sba->cmds_base, sba->cmds_dma_base);
+fail_free_resp_pool:
+ dma_free_coherent(sba->dma_dev.dev,
+ sba->max_resp_pool_size,
+ sba->resp_base, sba->resp_dma_base);
+ return ret;
+}
+
+static void sba_freeup_channel_resources(struct sba_device *sba)
+{
+ dmaengine_terminate_all(&sba->dma_chan);
+ dma_free_coherent(sba->dma_dev.dev, sba->max_cmds_pool_size,
+ sba->cmds_base, sba->cmds_dma_base);
+ dma_free_coherent(sba->dma_dev.dev, sba->max_resp_pool_size,
+ sba->resp_base, sba->resp_dma_base);
+ sba->resp_base = NULL;
+ sba->resp_dma_base = 0;
+}
+
+static int sba_async_register(struct sba_device *sba)
+{
+ int ret;
+ struct dma_device *dma_dev = &sba->dma_dev;
+
+ /* Initialize DMA channel cookie */
+ sba->dma_chan.device = dma_dev;
+ dma_cookie_init(&sba->dma_chan);
+
+ /* Initialize DMA device capability mask */
+ dma_cap_zero(dma_dev->cap_mask);
+ dma_cap_set(DMA_INTERRUPT, dma_dev->cap_mask);
+ dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
+ dma_cap_set(DMA_XOR, dma_dev->cap_mask);
+ dma_cap_set(DMA_PQ, dma_dev->cap_mask);
+
+ /*
+ * Set mailbox channel device as the base device of
+ * our dma_device because the actual memory accesses
+ * will be done by mailbox controller
+ */
+ dma_dev->dev = sba->mbox_dev;
+
+ /* Set base prep routines */
+ dma_dev->device_free_chan_resources = sba_free_chan_resources;
+ dma_dev->device_terminate_all = sba_device_terminate_all;
+ dma_dev->device_issue_pending = sba_issue_pending;
+ dma_dev->device_tx_status = sba_tx_status;
+
+ /* Set interrupt routine */
+ if (dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask))
+ dma_dev->device_prep_dma_interrupt = sba_prep_dma_interrupt;
+
+ /* Set memcpy routine */
+ if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask))
+ dma_dev->device_prep_dma_memcpy = sba_prep_dma_memcpy;
+
+ /* Set xor routine and capability */
+ if (dma_has_cap(DMA_XOR, dma_dev->cap_mask)) {
+ dma_dev->device_prep_dma_xor = sba_prep_dma_xor;
+ dma_dev->max_xor = sba->max_xor_srcs;
+ }
+
+ /* Set pq routine and capability */
+ if (dma_has_cap(DMA_PQ, dma_dev->cap_mask)) {
+ dma_dev->device_prep_dma_pq = sba_prep_dma_pq;
+ dma_set_maxpq(dma_dev, sba->max_pq_srcs, 0);
+ }
+
+ /* Initialize DMA device channel list */
+ INIT_LIST_HEAD(&dma_dev->channels);
+ list_add_tail(&sba->dma_chan.device_node, &dma_dev->channels);
+
+ /* Register with Linux async DMA framework*/
+ ret = dma_async_device_register(dma_dev);
+ if (ret) {
+ dev_err(sba->dev, "async device register error %d", ret);
+ return ret;
+ }
+
+ dev_info(sba->dev, "%s capabilities: %s%s%s%s\n",
+ dma_chan_name(&sba->dma_chan),
+ dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "interrupt " : "",
+ dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "memcpy " : "",
+ dma_has_cap(DMA_XOR, dma_dev->cap_mask) ? "xor " : "",
+ dma_has_cap(DMA_PQ, dma_dev->cap_mask) ? "pq " : "");
+
+ return 0;
+}
+
+static int sba_probe(struct platform_device *pdev)
+{
+ int i, ret = 0, mchans_count;
+ struct sba_device *sba;
+ struct platform_device *mbox_pdev;
+ struct of_phandle_args args;
+
+ /* Allocate main SBA struct */
+ sba = devm_kzalloc(&pdev->dev, sizeof(*sba), GFP_KERNEL);
+ if (!sba)
+ return -ENOMEM;
+
+ sba->dev = &pdev->dev;
+ platform_set_drvdata(pdev, sba);
+
+ /* Determine SBA version from DT compatible string */
+ if (of_device_is_compatible(sba->dev->of_node, "brcm,iproc-sba"))
+ sba->ver = SBA_VER_1;
+ else if (of_device_is_compatible(sba->dev->of_node,
+ "brcm,iproc-sba-v2"))
+ sba->ver = SBA_VER_2;
+ else
+ return -ENODEV;
+
+ /* Derived Configuration parameters */
+ switch (sba->ver) {
+ case SBA_VER_1:
+ sba->max_req = 1024;
+ sba->hw_buf_size = 4096;
+ sba->hw_resp_size = 8;
+ sba->max_pq_coefs = 6;
+ sba->max_pq_srcs = 6;
+ break;
+ case SBA_VER_2:
+ sba->max_req = 1024;
+ sba->hw_buf_size = 4096;
+ sba->hw_resp_size = 8;
+ sba->max_pq_coefs = 30;
+ /*
+ * We can support max_pq_srcs == max_pq_coefs because
+ * we are limited by number of SBA commands that we can
+ * fit in one message for underlying ring manager HW.
+ */
+ sba->max_pq_srcs = 12;
+ break;
+ default:
+ return -EINVAL;
+ }
+ sba->max_cmd_per_req = sba->max_pq_srcs + 3;
+ sba->max_xor_srcs = sba->max_cmd_per_req - 1;
+ sba->max_resp_pool_size = sba->max_req * sba->hw_resp_size;
+ sba->max_cmds_pool_size = sba->max_req *
+ sba->max_cmd_per_req * sizeof(u64);
+
+ /* Setup mailbox client */
+ sba->client.dev = &pdev->dev;
+ sba->client.rx_callback = sba_receive_message;
+ sba->client.tx_block = false;
+ sba->client.knows_txdone = false;
+ sba->client.tx_tout = 0;
+
+ /* Number of channels equals number of mailbox channels */
+ ret = of_count_phandle_with_args(pdev->dev.of_node,
+ "mboxes", "#mbox-cells");
+ if (ret <= 0)
+ return -ENODEV;
+ mchans_count = ret;
+ sba->mchans_count = 0;
+ atomic_set(&sba->mchans_current, 0);
+
+ /* Allocate mailbox channel array */
+ sba->mchans = devm_kcalloc(&pdev->dev, sba->mchans_count,
+ sizeof(*sba->mchans), GFP_KERNEL);
+ if (!sba->mchans)
+ return -ENOMEM;
+
+ /* Request mailbox channels */
+ for (i = 0; i < mchans_count; i++) {
+ sba->mchans[i] = mbox_request_channel(&sba->client, i);
+ if (IS_ERR(sba->mchans[i])) {
+ ret = PTR_ERR(sba->mchans[i]);
+ goto fail_free_mchans;
+ }
+ sba->mchans_count++;
+ }
+
+ /* Find-out underlying mailbox device */
+ ret = of_parse_phandle_with_args(pdev->dev.of_node,
+ "mboxes", "#mbox-cells", 0, &args);
+ if (ret)
+ goto fail_free_mchans;
+ mbox_pdev = of_find_device_by_node(args.np);
+ of_node_put(args.np);
+ if (!mbox_pdev) {
+ ret = -ENODEV;
+ goto fail_free_mchans;
+ }
+ sba->mbox_dev = &mbox_pdev->dev;
+
+ /* All mailbox channels should be of same ring manager device */
+ for (i = 1; i < mchans_count; i++) {
+ ret = of_parse_phandle_with_args(pdev->dev.of_node,
+ "mboxes", "#mbox-cells", i, &args);
+ if (ret)
+ goto fail_free_mchans;
+ mbox_pdev = of_find_device_by_node(args.np);
+ of_node_put(args.np);
+ if (sba->mbox_dev != &mbox_pdev->dev) {
+ ret = -EINVAL;
+ goto fail_free_mchans;
+ }
+ }
+
+ /* Register DMA device with linux async framework */
+ ret = sba_async_register(sba);
+ if (ret)
+ goto fail_free_mchans;
+
+ /* Prealloc channel resource */
+ ret = sba_prealloc_channel_resources(sba);
+ if (ret)
+ goto fail_async_dev_unreg;
+
+ /* Print device info */
+ dev_info(sba->dev, "%s using SBAv%d and %d mailbox channels",
+ dma_chan_name(&sba->dma_chan), sba->ver+1,
+ sba->mchans_count);
+
+ return 0;
+
+fail_async_dev_unreg:
+ dma_async_device_unregister(&sba->dma_dev);
+fail_free_mchans:
+ for (i = 0; i < sba->mchans_count; i++)
+ mbox_free_channel(sba->mchans[i]);
+ return ret;
+}
+
+static int sba_remove(struct platform_device *pdev)
+{
+ int i;
+ struct sba_device *sba = platform_get_drvdata(pdev);
+
+ sba_freeup_channel_resources(sba);
+
+ dma_async_device_unregister(&sba->dma_dev);
+
+ for (i = 0; i < sba->mchans_count; i++)
+ mbox_free_channel(sba->mchans[i]);
+
+ return 0;
+}
+
+static const struct of_device_id sba_of_match[] = {
+ { .compatible = "brcm,iproc-sba", },
+ { .compatible = "brcm,iproc-sba-v2", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sba_of_match);
+
+static struct platform_driver sba_driver = {
+ .probe = sba_probe,
+ .remove = sba_remove,
+ .driver = {
+ .name = "bcm-sba-raid",
+ .of_match_table = sba_of_match,
+ },
+};
+module_platform_driver(sba_driver);
+
+MODULE_DESCRIPTION("Broadcom SBA RAID driver");
+MODULE_AUTHOR("Anup Patel <anup.patel@broadcom.com>");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v6 0/4] Broadcom SBA RAID support
From: Anup Patel @ 2017-03-06 9:43 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar
Cc: devicetree, Anup Patel, Scott Branden, Jon Mason, Ray Jui,
linux-kernel, linux-raid, bcm-kernel-feedback-list, linux-crypto,
Rob Rice, dmaengine, Dan Williams, linux-arm-kernel
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
^ permalink raw reply
* Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex
From: Dmitry Vyukov @ 2017-03-06 9:36 UTC (permalink / raw)
To: Herbert Xu, David Miller, linux-crypto, LKML, Eric Dumazet,
Cong Wang, netdev
Cc: syzkaller
In-Reply-To: <CACT4Y+bJ1-d3DhCvzEN0PeDd7+P2LNgjF2NHwALXBubOKaOEsw@mail.gmail.com>
On Sun, Mar 5, 2017 at 6:36 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Sun, Mar 5, 2017 at 4:08 PM, Dmitry Vyukov <dvyukov@google.com> 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: [<ffffffff837df634>]
>> __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
>>
>> but task is already holding lock:
>> (crypto_alg_sem){+++++.}, at: [<ffffffff821cd1f6>]
>> 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 fs/read_write.c:510
>> vfs_write+0x187/0x530 fs/read_write.c:558
>> SYSC_write fs/read_write.c:605 [inline]
>> SyS_write+0xfb/0x230 fs/read_write.c:597
>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> -> #1 (genl_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
>> genl_lock net/netlink/genetlink.c:32 [inline]
>> genl_lock_dumpit+0x41/0x90 net/netlink/genetlink.c:478
>> 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 fs/read_write.c:510
>> vfs_write+0x187/0x530 fs/read_write.c:558
>> SYSC_write fs/read_write.c:605 [inline]
>> SyS_write+0xfb/0x230 fs/read_write.c:597
>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> -> #0 (nlk->cb_mutex){+.+.+.}:
>> check_prev_add kernel/locking/lockdep.c:1830 [inline]
>> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
>> 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
>> __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
>> netlink_dump_start include/linux/netlink.h:165 [inline]
>> crypto_user_rcv_msg+0x2ad/0x4f0 crypto/crypto_user.c:517
>> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
>> crypto_netlink_rcv+0x2a/0x40 crypto/crypto_user.c:538
>> 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
>> ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
>> __sys_sendmsg+0x138/0x300 net/socket.c:2019
>> SYSC_sendmsg net/socket.c:2030 [inline]
>> SyS_sendmsg+0x2d/0x50 net/socket.c:2026
>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> other info that might help us debug this:
>>
>> Chain exists of:
>> nlk->cb_mutex --> sk_lock-AF_INET --> crypto_alg_sem
>>
>> Possible unsafe locking scenario:
>>
>> CPU0 CPU1
>> ---- ----
>> lock(crypto_alg_sem);
>> lock(sk_lock-AF_INET);
>> lock(crypto_alg_sem);
>> lock(nlk->cb_mutex);
>>
>> *** DEADLOCK ***
>>
>> 2 locks held by syz-executor6/6143:
>> #0: (crypto_cfg_mutex){+.+...}, at: [<ffffffff821cad9b>]
>> crypto_netlink_rcv+0x1b/0x40 crypto/crypto_user.c:537
>> #1: (crypto_alg_sem){+++++.}, at: [<ffffffff821cd1f6>]
>> crypto_user_rcv_msg+0x136/0x4f0 crypto/crypto_user.c:507
>>
>> stack backtrace:
>> CPU: 0 PID: 6143 Comm: syz-executor6 Not tainted 4.10.0+ #5
>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>> BIOS Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:16 [inline]
>> dump_stack+0x2ee/0x3ef lib/dump_stack.c:52
>> print_circular_bug+0x307/0x3b0 kernel/locking/lockdep.c:1204
>> check_prev_add kernel/locking/lockdep.c:1830 [inline]
>> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
>> 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
>> __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
>> netlink_dump_start include/linux/netlink.h:165 [inline]
>> crypto_user_rcv_msg+0x2ad/0x4f0 crypto/crypto_user.c:517
>> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
>> crypto_netlink_rcv+0x2a/0x40 crypto/crypto_user.c:538
>> 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
>> ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
>> __sys_sendmsg+0x138/0x300 net/socket.c:2019
>> SYSC_sendmsg net/socket.c:2030 [inline]
>> SyS_sendmsg+0x2d/0x50 net/socket.c:2026
>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
>
>
> Another one involving tcp_md5sig_mutex:
>
>
> ======================================================
> [ INFO: possible circular locking dependency detected ]
> SELinux: unrecognized netlink message: protocol=9 nlmsg_type=2
> sclass=netlink_audit_socket pig=4033 comm=syz-executor4
> 4.10.0+ #5 Not tainted
> -------------------------------------------------------
> syz-executor8/4018 is trying to acquire lock:
> (crypto_alg_sem){++++++}, at: [<ffffffff82193473>]
> crypto_alg_lookup+0x23/0x50 crypto/api.c:199
>
> but task is already holding lock:
> (tcp_md5sig_mutex){+.+...}, at: [<ffffffff838e4efa>]
> tcp_alloc_md5sig_pool+0x4a/0x470 net/ipv4/tcp.c:3196
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #5 (tcp_md5sig_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
> tcp_alloc_md5sig_pool+0x4a/0x470 net/ipv4/tcp.c:3196
> tcp_md5_do_add+0x1d8/0x5d0 net/ipv4/tcp_ipv4.c:969
> tcp_v4_parse_md5_keys+0x1c7/0x2b0 net/ipv4/tcp_ipv4.c:1037
> do_tcp_setsockopt.isra.36+0x657/0x20a0 net/ipv4/tcp.c:2668
> 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
> do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:281
> return_from_SYSCALL_64+0x0/0x7a
>
> -> #4 (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]
> do_ip_setsockopt.isra.12+0x301/0x3760 net/ipv4/ip_sockglue.c:653
> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1265
> tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2731
> 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 (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
> nl80211_prepare_wdev_dump.isra.37+0x2c/0x5d0 net/wireless/nl80211.c:548
> nl80211_dump_station+0x178/0xd80 net/wireless/nl80211.c:4455
> 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 fs/read_write.c:510
> vfs_write+0x187/0x530 fs/read_write.c:558
> SYSC_write fs/read_write.c:605 [inline]
> SyS_write+0xfb/0x230 fs/read_write.c:597
> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> -> #2 (genl_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
> genl_lock net/netlink/genetlink.c:32 [inline]
> genl_lock_dumpit+0x41/0x90 net/netlink/genetlink.c:478
> 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 fs/read_write.c:510
> vfs_write+0x187/0x530 fs/read_write.c:558
> SYSC_write fs/read_write.c:605 [inline]
> SyS_write+0xfb/0x230 fs/read_write.c:597
> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> -> #1 (nlk->cb_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
> __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
> netlink_dump_start include/linux/netlink.h:165 [inline]
> crypto_user_rcv_msg+0x2ad/0x4f0 crypto/crypto_user.c:517
> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
> crypto_netlink_rcv+0x2a/0x40 crypto/crypto_user.c:538
> 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
> ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
> __sys_sendmsg+0x138/0x300 net/socket.c:2019
> SYSC_sendmsg net/socket.c:2030 [inline]
> SyS_sendmsg+0x2d/0x50 net/socket.c:2026
> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> -> #0 (crypto_alg_sem){++++++}:
> check_prev_add kernel/locking/lockdep.c:1830 [inline]
> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
> 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_find_alg crypto/api.c:500 [inline]
> crypto_alloc_tfm+0x101/0x2e0 crypto/api.c:533
> crypto_alloc_ahash+0x2c/0x40 crypto/ahash.c:525
> __tcp_alloc_md5sig_pool net/ipv4/tcp.c:3158 [inline]
> tcp_alloc_md5sig_pool+0x85/0x470 net/ipv4/tcp.c:3199
> tcp_md5_do_add+0x1d8/0x5d0 net/ipv4/tcp_ipv4.c:969
> tcp_v4_parse_md5_keys+0x1c7/0x2b0 net/ipv4/tcp_ipv4.c:1037
> do_tcp_setsockopt.isra.36+0x657/0x20a0 net/ipv4/tcp.c:2668
> 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
> do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:281
> return_from_SYSCALL_64+0x0/0x7a
>
> other info that might help us debug this:
>
> Chain exists of:
> crypto_alg_sem --> sk_lock-AF_INET --> tcp_md5sig_mutex
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(tcp_md5sig_mutex);
> lock(sk_lock-AF_INET);
> lock(tcp_md5sig_mutex);
> lock(crypto_alg_sem);
>
> *** DEADLOCK ***
>
> 2 locks held by syz-executor8/4018:
> #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838e7a26>] lock_sock
> include/net/sock.h:1460 [inline]
> #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838e7a26>]
> do_tcp_setsockopt.isra.36+0x216/0x20a0 net/ipv4/tcp.c:2466
> #1: (tcp_md5sig_mutex){+.+...}, at: [<ffffffff838e4efa>]
> tcp_alloc_md5sig_pool+0x4a/0x470 net/ipv4/tcp.c:3196
>
> stack backtrace:
> CPU: 0 PID: 4018 Comm: syz-executor8 Not tainted 4.10.0+ #5
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:16 [inline]
> dump_stack+0x2ee/0x3ef lib/dump_stack.c:52
> print_circular_bug+0x307/0x3b0 kernel/locking/lockdep.c:1204
> check_prev_add kernel/locking/lockdep.c:1830 [inline]
> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
> 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_find_alg crypto/api.c:500 [inline]
> crypto_alloc_tfm+0x101/0x2e0 crypto/api.c:533
> crypto_alloc_ahash+0x2c/0x40 crypto/ahash.c:525
> __tcp_alloc_md5sig_pool net/ipv4/tcp.c:3158 [inline]
> tcp_alloc_md5sig_pool+0x85/0x470 net/ipv4/tcp.c:3199
> tcp_md5_do_add+0x1d8/0x5d0 net/ipv4/tcp_ipv4.c:969
> tcp_v4_parse_md5_keys+0x1c7/0x2b0 net/ipv4/tcp_ipv4.c:1037
> do_tcp_setsockopt.isra.36+0x657/0x20a0 net/ipv4/tcp.c:2668
> 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
> do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:281
Another one:
======================================================
[ INFO: possible circular locking dependency detected ]
4.10.0+ #6 Not tainted
-------------------------------------------------------
syz-executor8/3613 is trying to acquire lock:
(sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83b72eb9>] lock_sock
include/net/sock.h:1460 [inline]
(sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83b72eb9>]
do_ipv6_setsockopt.isra.11+0x229/0x36e0 net/ipv6/ipv6_sockglue.c:167
but task is already holding lock:
(rtnl_mutex){+.+.+.}, at: [<ffffffff8370a197>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:70
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #4 (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_node_dump_monitor+0x260/0x510 net/tipc/node.c:2128
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 fs/read_write.c:510
vfs_write+0x187/0x530 fs/read_write.c:558
SYSC_write fs/read_write.c:605 [inline]
SyS_write+0xfb/0x230 fs/read_write.c:597
entry_SYSCALL_64_fastpath+0x1f/0xc2
-> #3 (genl_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
genl_lock net/netlink/genetlink.c:32 [inline]
genl_lock_dumpit+0x41/0x90 net/netlink/genetlink.c:478
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 fs/read_write.c:510
vfs_write+0x187/0x530 fs/read_write.c:558
SYSC_write fs/read_write.c:605 [inline]
SyS_write+0xfb/0x230 fs/read_write.c:597
entry_SYSCALL_64_fastpath+0x1f/0xc2
-> #2 (nlk->cb_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
__netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
netlink_dump_start include/linux/netlink.h:165 [inline]
crypto_user_rcv_msg+0x2ad/0x4f0 crypto/crypto_user.c:517
netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
crypto_netlink_rcv+0x2a/0x40 crypto/crypto_user.c:538
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
___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
__sys_sendmsg+0x138/0x300 net/socket.c:2019
SYSC_sendmsg net/socket.c:2030 [inline]
SyS_sendmsg+0x2d/0x50 net/socket.c:2026
entry_SYSCALL_64_fastpath+0x1f/0xc2
-> #1 (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_find_alg crypto/api.c:500 [inline]
crypto_alloc_tfm+0x101/0x2e0 crypto/api.c:533
crypto_alloc_shash+0x2c/0x40 crypto/shash.c:433
sctp_listen_start net/sctp/socket.c:6969 [inline]
sctp_inet_listen+0x5b7/0x7e0 net/sctp/socket.c:7054
SYSC_listen net/socket.c:1440 [inline]
SyS_listen+0x2c9/0x390 net/socket.c:1426
entry_SYSCALL_64_fastpath+0x1f/0xc2
-> #0 (sk_lock-AF_INET6){+.+.+.}:
check_prev_add kernel/locking/lockdep.c:1830 [inline]
check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
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]
do_ipv6_setsockopt.isra.11+0x229/0x36e0 net/ipv6/ipv6_sockglue.c:167
ipv6_setsockopt+0x9b/0x140 net/ipv6/ipv6_sockglue.c:919
tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2731
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
other info that might help us debug this:
Chain exists of:
sk_lock-AF_INET6 --> genl_mutex --> rtnl_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(rtnl_mutex);
lock(genl_mutex);
lock(rtnl_mutex);
lock(sk_lock-AF_INET6);
*** DEADLOCK ***
1 lock held by syz-executor8/3613:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8370a197>]
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
stack backtrace:
CPU: 1 PID: 3613 Comm: syz-executor8 Not tainted 4.10.0+ #6
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x2ee/0x3ef lib/dump_stack.c:52
print_circular_bug+0x307/0x3b0 kernel/locking/lockdep.c:1204
check_prev_add kernel/locking/lockdep.c:1830 [inline]
check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
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]
do_ipv6_setsockopt.isra.11+0x229/0x36e0 net/ipv6/ipv6_sockglue.c:167
ipv6_setsockopt+0x9b/0x140 net/ipv6/ipv6_sockglue.c:919
tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2731
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox