Re: [RFC PATCH 13/12] Retpoline vs. CONFIG_TRIM_UNUSED_SYMBOLS

[David Woodhouse]

On Sun, 2018-01-07 at 00:10 +, David Woodhouse wrote:
> Arjan pointed out that CONFIG_TRIM_UNUSED_SYMBOLS *really* doesn't like
> the dot in the symbols that GCC uses for the thunks.
> 
> This seems to work, although my eyes are bleeding just a little bit.
> 
> Given this, and the hack we already needed for MODVERSIONS, I wonder if
> a better approach might be to export the thunks using underscores in
> place of the dots, which is a relatively simple abuse of
> __EXPORT_SYMBOL(__x86_indirect_thunk_foo,__x86.indirect_thunk.foo,),
> and then have a hack either when generating or loading modules to do
> the same replacement.

Alternatively, and much simpler... HJ (or Igor), please can we change
the GCC patches so that the __x86.indirect_thunk.rxx symbols don't have
those awful dots in them? They are causing *lots* of pain.

Or we could build *modules* with the inline thunk and lose the ability
to ALTERNATIVE it away, I suppose.

> diff --git a/arch/x86/lib/retpoline.S b/arch/x86/lib/retpoline.S
> index ccb117a4588b..64d7a45ea954 100644
> --- a/arch/x86/lib/retpoline.S
> +++ b/arch/x86/lib/retpoline.S
> @@ -8,7 +8,13 @@
>  #include 
>  #include 
>  
> -.macro THUNK reg
> +#ifdef CONFIG_TRIM_UNUSED_KSYMS
> +#define EXPORT_REG(reg) __is_defined(__KSYM___x86_indirect_thunk_ ## reg)
> +#else
> +#define EXPORT_REG(reg)  1
> +#endif
> +
> +.macro THUNK reg export
>   .section .text.__x86.indirect_thunk.\reg
>  
>  ENTRY(__x86.indirect_thunk.\reg)
> @@ -16,15 +22,33 @@ ENTRY(__x86.indirect_thunk.\reg)
>   NOSPEC_JMP %\reg
>   CFI_ENDPROC
>  ENDPROC(__x86.indirect_thunk.\reg)
> -EXPORT_SYMBOL(__x86.indirect_thunk.\reg)
> +
> +.if \export
> + EXPORT_SYMBOL_FORCE(__x86.indirect_thunk.\reg)
> +.endif
>  .endm
>  
> -#ifdef CONFIG_64BIT
> -.irp reg rax rbx rcx rdx rsi rdi rbp r8 r9 r10 r11 r12 r13 r14 r15
> - THUNK \reg
> -.endr
> +#ifdef __KSYM_DEPS__
> +#define GENERATE_THUNK(reg) EXPORT_SYMBOL(__x86.indirect_thunk. ## reg)
>  #else
> -.irp reg eax ebx ecx edx esi edi ebp
> - THUNK \reg
> -.endr
> +#define GENERATE_THUNK(reg) THUNK reg EXPORT_REG(reg)
> +#endif
> +
> +GENERATE_THUNK(_ASM_AX)
> +GENERATE_THUNK(_ASM_BX)
> +GENERATE_THUNK(_ASM_CX)
> +GENERATE_THUNK(_ASM_DX)
> +GENERATE_THUNK(_ASM_SI)
> +GENERATE_THUNK(_ASM_DI)
> +GENERATE_THUNK(_ASM_BP)
> +GENERATE_THUNK(_ASM_SP)
> +#ifdef CONFIG_64BIT
> +GENERATE_THUNK(r8)
> +GENERATE_THUNK(r9)
> +GENERATE_THUNK(r10)
> +GENERATE_THUNK(r11)
> +GENERATE_THUNK(r12)
> +GENERATE_THUNK(r13)
> +GENERATE_THUNK(r14)
> +GENERATE_THUNK(r15)
>  #endif
> diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
> index 719db1968d81..b13bb65e2530 100644
> --- a/include/asm-generic/export.h
> +++ b/include/asm-generic/export.h
> @@ -63,33 +63,33 @@ KSYM(__kcrctab_\name):
>  
>  #if defined(__KSYM_DEPS__)
>  
> -#define __EXPORT_SYMBOL(sym, val, sec)   === __KSYM_##sym ===
> +#define __EXPORT_SYMBOL(sym, val, sec, force)=== __KSYM_##sym ===
>  
>  #elif defined(CONFIG_TRIM_UNUSED_KSYMS)
>  
>  #include 
>  #include 
>  
> -#define __EXPORT_SYMBOL(sym, val, sec)   \
> - __cond_export_sym(sym, val, sec, __is_defined(__KSYM_##sym))
> +#define __EXPORT_SYMBOL(sym, val, sec, force)\
> +  __cond_export_sym(sym, val, sec, __or(force, 
> __is_defined(__KSYM_##sym)))
>  #define __cond_export_sym(sym, val, sec, conf)   \
>   ___cond_export_sym(sym, val, sec, conf)
>  #define ___cond_export_sym(sym, val, sec, enabled)   \
>   __cond_export_sym_##enabled(sym, val, sec)
>  #define __cond_export_sym_1(sym, val, sec) ___EXPORT_SYMBOL sym, val, sec
>  #define __cond_export_sym_0(sym, val, sec) /* nothing */
> -
>  #else
> -#define __EXPORT_SYMBOL(sym, val, sec) ___EXPORT_SYMBOL sym, val, sec
> +#define __EXPORT_SYMBOL(sym, val, sec, force)___EXPORT_SYMBOL sym, 
> val, sec
>  #endif
>  
>  #define EXPORT_SYMBOL(name)  \
> - __EXPORT_SYMBOL(name, KSYM_FUNC(KSYM(name)),)
> + __EXPORT_SYMBOL(name, KSYM_FUNC(KSYM(name)), , 0)
>  #define EXPORT_SYMBOL_GPL(name)  \
> - __EXPORT_SYMBOL(name, KSYM_FUNC(KSYM(name)), _gpl)
> + __EXPORT_SYMBOL(name, KSYM_FUNC(KSYM(name)), _gpl, 0)
>  #define EXPORT_DATA_SYMBOL(name) \
> - __EXPORT_SYMBOL(name, KSYM(name),)
> + __EXPORT_SYMBOL(name, KSYM(name), , 0)
>  #define EXPORT_DATA_SYMBOL_GPL(name) \
> - __EXPORT_SYMBOL(name, KSYM(name),_gpl)
> -
> + __EXPORT_SYMBOL(name, KSYM(name), _gpl, 0)
> +#define EXPORT_SYMBOL_FORCE(name)\
> + __EXPORT_SYMBOL(name, KSYM(name), , 1)
>  #endif
> diff --git a/scripts/adjust_autoksyms.sh b/scripts/adjust_autoksyms.sh
> index 513da1a4a2da..991cd136291b 100755
> --- a/scripts/adjust_autoksyms.sh
> +++ b/scripts/adjust_autoksyms.sh
> @@ -60,7 +60,7 @@ cat > "$new_ksyms_file" << EOT
>  
>  EOT
>  [ "$(ls -A "$M

Re: "BUG: using smp_processor_id() in preemptible" with KPTI on 4.14.11

[Greg Kroah-Hartman]

On Sat, Jan 06, 2018 at 10:38:38PM +0100, Thomas Zeitlhofer wrote:
> On Thu, Jan 04, 2018 at 07:38:00PM +0100, Thomas Zeitlhofer wrote:
> > On Thu, Jan 04, 2018 at 06:07:12PM +0100, Peter Zijlstra wrote:
> > > On Thu, Jan 04, 2018 at 04:37:24PM +0100, Thomas Gleixner wrote:
> > > > > Yes:
> > > > > 
> > > > >BUG: using smp_processor_id() in preemptible [] code: 
> > > > > ovsdb-server/4498
> > > > >caller is native_flush_tlb_single+0x57/0xc0
> > > > >CPU: 2 PID: 4498 Comm: ovsdb-server Not tainted 
> > > > > 4.15.0-rc6-kvm-00423-gea1908c252eb #3
> > > > >Hardware name: MSI MS-7798/B75MA-P45 (MS-7798), BIOS V1.9 
> > > > > 09/30/2013
> > > > >Call Trace:
> > > > > dump_stack+0x5c/0x86
> > > > > check_preemption_disabled+0xdd/0xe0
> > > > > native_flush_tlb_single+0x57/0xc0
> > > > > ? __set_pte_vaddr+0x2d/0x40
> > > > > __set_pte_vaddr+0x2d/0x40
> > > > > set_pte_vaddr+0x2f/0x40
> > > > > cea_set_pte+0x30/0x40
> > > > > ds_update_cea.constprop.4+0x4d/0x70
> > > > > reserve_ds_buffers+0x159/0x410
> > > > > ? wp_page_copy+0x370/0x6c0
> > > > > x86_reserve_hardware+0x150/0x160
> > > > > x86_pmu_event_init+0x3e/0x1f0
> > > > > perf_try_init_event+0x69/0x80
> > > > > perf_event_alloc+0x652/0x740
> > > > > SyS_perf_event_open+0x3f6/0xd60
> > > > > do_syscall_64+0x5c/0x190
> > > > > entry_SYSCALL64_slow_path+0x25/0x25
> > > > >RIP: 0033:0x72bff0a3c0b9
> > > > >RSP: 002b:7ffed11c2f18 EFLAGS: 0206 ORIG_RAX: 
> > > > > 012a
> > > > >RAX: ffda RBX: 7ffed11c30f0 RCX: 72bff0a3c0b9
> > > > >RDX:  RSI:  RDI: 7ffed11c2f20
> > > > >RBP:  R08:  R09: 0070
> > > > >R10:  R11: 0206 R12: 0008
> > > > >R13:  R14: 7ffed11c30d0 R15: 60986ecfb600
> > > 
> > > Fun, so set_pte_vaddr() and the whole cpu_entry_area are supposed to be
> > > per CPU. But the DS crud does cross CPU updates of those tables.
> > > 
> > > So we need some additional fun and games..
> > > 
> > > How's the below?
> > [...]
> > 
> > Looks good - I have successfully tested it on top of 4.14.11 and
> > 4.15-rc6. In both cases, the error message is gone when this patch is
> > applied.
> 
> While solving the previous problem, this patch also introduces new "fun
> and games"...  
> 
> Now, terminating a systemd-nspawn container, reliably crashes the host
> (so far tested only on Haswell, if that matters). Once, I was able to
> capture the following trace:

Is this also reproducable on Linus's tree right now?

I've been running nspawn containers on it with no issues like this at
all :(

thanks,

greg k-h

Re: atm/clip: Use seq_puts() in svc_addr()

[SF Markus Elfring]

>> Two strings should be quickly put into a sequence by two function calls.
>> Thus use the function "seq_puts" instead of "seq_printf".
>>
>> This issue was detected by using the Coccinelle software.
> 
> Can you please explain what the issue really is and what you're trying
> to do here?

Is the function "seq_puts" a bit more efficient for the desired output
of a single string in comparison to calling the function "seq_printf"
for this purpose?


> One shouldn't need to dig into Coccinelle patterns to find
> out what you mean,

Why did an attribution for a software tool confuse you?


> and "strings should be quickly put into a sequence"
> isn't terribly helpful.

Which wording would you find more appropriate for the suggested
adjustment of these function calls?

Regards,
Markus

Re: [PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

[Greg KH]

On Sat, Jan 06, 2018 at 04:25:19PM -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Jan 06, 2018 at 10:10:59AM -0800, Tim Chen wrote:
> > 
> > 
> > On 01/06/2018 12:54 AM, Greg KH wrote:
> > > On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
> > >> From: Tim Chen 
> > >> From: Andrea Arcangeli 
> > >>
> > >> There are 2 ways to control IBRS
> > >>
> > >> 1. At boot time
> > >> noibrs kernel boot parameter will disable IBRS usage
> > >>
> > >> Otherwise if the above parameters are not specified, the system
> > >> will enable ibrs and ibpb usage if the cpu supports it.
> > >>
> > >> 2. At run time
> > >> echo 0 > /sys/kernel/debug/x86/ibrs_enabled will turn off IBRS
> > >> echo 1 > /sys/kernel/debug/x86/ibrs_enabled will turn on IBRS in 
> > >> kernel
> > >> echo 2 > /sys/kernel/debug/x86/ibrs_enabled will turn on IBRS in 
> > >> both userspace and kernel
> > >>
> 
> 
> This is going to create headaches in the future.
> 
> That is future CPUs there will be no need for this MSR nor retpoline as
> the CPUs will observe correctness when switching .. rings/vm-exits/etc
> and I would assume that 'ibrs_enabled' will return 0.
> 
> And that will make folks scared and run to support/Intel with
> complaints.
> 
> Furthmore with the 'retpoline' work you can disable IBRS and instead use
> 'retpoline's as mitigation - and again the 'ibrs_enabled' is now zero.
> Cue in horde of customers calling support.
> 
> Would it be better to have an global /sys/../spectre_resistent instead
> of these 'well, check if the repoline sysfs is enabled, or if that is
> not, then look at the cpuid flags'.
> 
> It would be good to have this future proof.

It's a debugfs api, it can be changed at any time, to be anything we
want, and all is fine :)

Let's get this all working first please, and then a "real" api can be
designed and implemented to please everyone.

thanks,

greg k-h

Dear Talented

[Kim Sharma]

Dear Talented,

I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a
Film Corporation Located in the United State, is Soliciting for the
Right to use Your Photo/Face and Personality as One of the Semi -Major
Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story
of Anubis (Anubis 2018) The Movie is Currently Filming (In
Production) Please Note That There Will Be No Auditions, Traveling or
Any Special / Professional Acting Skills, Since the Production of This
Movie Will Be Done with our State of Art Computer -Generating Imagery
Equipment. We Are Prepared to Pay the Total Sum of $620,000.00 USD. For
More Information/Understanding, Please Write us on the E-Mail Below.
CONTACT EMAIL: blueskyfilms.stud...@usa.com
All Reply to: blueskyfilms.stud...@usa.com
Note: Only the Response send to this mail will be Given a Prior
Consideration.


Talent Scout
Kim Sharma

Re: [RFC] memdup_user() and friends

[Alexey Dobriyan]

> Objections?

No objections in particular except the amount of mirrored allocator
interfaces is getting pretty ridiculous.

Another thing, blindly changing kmalloc+copy_from_user to memdup_user
can be wrong because of GFP_KERNEL_ACCOUNT if the memory is allocated
persistently.

Re: metag build error in -next due to 'fs, elf: drop MAP_FIXED usage from elf_map'

[Michal Hocko]

On Sat 06-01-18 17:07:33, Guenter Roeck wrote:
> The following build error is seen when building metag:meta2_defconfig
> or metag:tz1090_defconfig.
> 
> arch/metag/kernel/process.c: In function '__metag_elf_map':
> arch/metag/kernel/process.c:421: error: 'tsk' undeclared

Sorry about that and thanks for your report. The following should fix
the issue. Andrew, could you fold it to the original patch please?
---
>From 64da2e0c134ecf3936a4c36b949bcf2cdc98977e Mon Sep 17 00:00:00 2001
From: Michal Hocko 
Date: Sun, 7 Jan 2018 09:47:41 +0100
Subject: [PATCH] fs-elf-drop-map_fixed-usage-from-elf_map-fix-fix

The following build error is seen when building metag:meta2_defconfig
or metag:tz1090_defconfig.

arch/metag/kernel/process.c: In function '__metag_elf_map':
arch/metag/kernel/process.c:421: error: 'tsk' undeclared

Reported-by: Guenter Roeck 
Signed-off-by: Michal Hocko 
---
 arch/metag/kernel/process.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/metag/kernel/process.c b/arch/metag/kernel/process.c
index 9e007195038d..0cca2c95a091 100644
--- a/arch/metag/kernel/process.c
+++ b/arch/metag/kernel/process.c
@@ -419,7 +419,7 @@ unsigned long __metag_elf_map(struct file *filep, unsigned 
long addr,
 
if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr))
pr_info("%d (%s): Uhuuh, elf segment at %p requested but the 
memory is mapped already\n",
-   task_pid_nr(current), tsk->comm, (void *)addr);
+   task_pid_nr(current), current->comm, (void 
*)addr);
 
if (!BAD_ADDR(map_addr) && tcm_tag != TCM_INVALID_TAG) {
struct tcm_allocation *tcm;
-- 
2.15.1

-- 
Michal Hocko
SUSE Labs

[PATCH] NFSv4.1: Ensure 'nfs4_sp4_select_mode()' can report -EINVAL when needed

[Christophe JAILLET]

Since commit 937e3133cd0b, 'nfs4_sp4_select_mode()' always return 0.
Based on the way this commit is written (direct return replaced by some
'ret = -EXXX'), it is likely that returning this error code is expected.

Fixes: 937e3133cd0b ("NFSv4.1: Ensure we clear the SP4_MACH_CRED flags in 
nfs4_sp4_select_mode()")
Signed-off-by: Christophe JAILLET 
---
Untested and not sure at all if correct...
---
 fs/nfs/nfs4proc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 17a03f2c4330..ae00ac59f59b 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -7584,7 +7584,7 @@ static int nfs4_sp4_select_mode(struct nfs_client *clp,
}
 out:
clp->cl_sp4_flags = flags;
-   return 0;
+   return ret;
 }
 
 struct nfs41_exchange_id_data {
-- 
2.14.1

Re: "BUG: using smp_processor_id() in preemptible" with KPTI on 4.14.11

[Thomas Zeitlhofer]

On Sun, Jan 07, 2018 at 09:17:18AM +0100, Greg Kroah-Hartman wrote:
> On Sat, Jan 06, 2018 at 10:38:38PM +0100, Thomas Zeitlhofer wrote:
> > On Thu, Jan 04, 2018 at 07:38:00PM +0100, Thomas Zeitlhofer wrote:
> > > On Thu, Jan 04, 2018 at 06:07:12PM +0100, Peter Zijlstra wrote:
> > > > On Thu, Jan 04, 2018 at 04:37:24PM +0100, Thomas Gleixner wrote:
> > > > > > Yes:
> > > > > > 
> > > > > >BUG: using smp_processor_id() in preemptible [] code: 
> > > > > > ovsdb-server/4498
> > > > > >caller is native_flush_tlb_single+0x57/0xc0
> > > > > >CPU: 2 PID: 4498 Comm: ovsdb-server Not tainted 
> > > > > > 4.15.0-rc6-kvm-00423-gea1908c252eb #3
> > > > > >Hardware name: MSI MS-7798/B75MA-P45 (MS-7798), BIOS V1.9 
> > > > > > 09/30/2013
> > > > > >Call Trace:
> > > > > > dump_stack+0x5c/0x86
> > > > > > check_preemption_disabled+0xdd/0xe0
> > > > > > native_flush_tlb_single+0x57/0xc0
> > > > > > ? __set_pte_vaddr+0x2d/0x40
> > > > > > __set_pte_vaddr+0x2d/0x40
> > > > > > set_pte_vaddr+0x2f/0x40
> > > > > > cea_set_pte+0x30/0x40
> > > > > > ds_update_cea.constprop.4+0x4d/0x70
> > > > > > reserve_ds_buffers+0x159/0x410
> > > > > > ? wp_page_copy+0x370/0x6c0
> > > > > > x86_reserve_hardware+0x150/0x160
> > > > > > x86_pmu_event_init+0x3e/0x1f0
> > > > > > perf_try_init_event+0x69/0x80
> > > > > > perf_event_alloc+0x652/0x740
> > > > > > SyS_perf_event_open+0x3f6/0xd60
> > > > > > do_syscall_64+0x5c/0x190
> > > > > > entry_SYSCALL64_slow_path+0x25/0x25
> > > > > >RIP: 0033:0x72bff0a3c0b9
> > > > > >RSP: 002b:7ffed11c2f18 EFLAGS: 0206 ORIG_RAX: 
> > > > > > 012a
> > > > > >RAX: ffda RBX: 7ffed11c30f0 RCX: 72bff0a3c0b9
> > > > > >RDX:  RSI:  RDI: 7ffed11c2f20
> > > > > >RBP:  R08:  R09: 0070
> > > > > >R10:  R11: 0206 R12: 0008
> > > > > >R13:  R14: 7ffed11c30d0 R15: 60986ecfb600
> > > > 
> > > > Fun, so set_pte_vaddr() and the whole cpu_entry_area are supposed to be
> > > > per CPU. But the DS crud does cross CPU updates of those tables.
> > > > 
> > > > So we need some additional fun and games..
> > > > 
> > > > How's the below?
> > > [...]
> > > 
> > > Looks good - I have successfully tested it on top of 4.14.11 and
> > > 4.15-rc6. In both cases, the error message is gone when this patch is
> > > applied.
> > 
> > While solving the previous problem, this patch also introduces new "fun
> > and games"...  
> > 
> > Now, terminating a systemd-nspawn container, reliably crashes the host
> > (so far tested only on Haswell, if that matters). Once, I was able to
> > capture the following trace:
> 
> Is this also reproducable on Linus's tree right now?

It is reproducible with this patch on top of 4.15-rc6 (might be able to
test Linus's current tree later that day). 

Thanks,

Thomas

ppc elf_map breakage with MAP_FIXED_NOREPLACE (was: Re: mmotm 2018-01-04-16-19 uploaded)

[Michal Hocko]

On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
> On 01/05/2018 02:16 PM, Michal Hocko wrote:
[...]
> > Could you give us more information about the failure please. Debugging
> > patch from http://lkml.kernel.org/r/20171218091302.gl16...@dhcp22.suse.cz
> > should help to see what is the clashing VMA.
> 
> Seems like its re-requesting the same mapping again.

It always seems to be the same mapping which is a bit strange as we
have multiple binaries here. Are these binaries any special? Does this
happen to all bianries (except for init which has obviously started
successfully)? Could you add an additional debugging (at the do_mmap
layer) to see who is requesting the mapping for the first time?

> [   23.423642] 9148 (sed): Uhuuh, elf segment at 1003 requested 
> but the memory is mapped already
> [   23.423706] requested [1003, 1004] mapped [1003, 1004] 
> 100073 anon

I also find it a bit unexpected that this is an anonymous mapping
because the elf loader should always map a file backed one.

> [   23.426089] 9151 (sed): Uhuuh, elf segment at 1003 requested 
> but the memory is mapped already
> [   23.426232] requested [1003, 1004] mapped [1003, 1004] 
> 100073 anon
> [   23.429048] 9154 (sed): Uhuuh, elf segment at 1003 requested 
> but the memory is mapped already
> [   23.429196] requested [1003, 1004] mapped [1003, 1004] 
> 100073 anon
> [   23.482766] 9164 (sed): Uhuuh, elf segment at 1003 requested 
> but the memory is mapped already
> [   23.482904] requested [1003, 1004] mapped [1003, 1004] 
> 100073 anon
> [   23.485849] 9167 (sed): Uhuuh, elf segment at 1003 requested 
> but the memory is mapped already
> [   23.485945] requested [1003, 1004] mapped [1003, 1004] 
> 100073 anon
> [   76.041836] 9262 (hostname): Uhuuh, elf segment at 1002 
> requested but the memory is mapped already
> [   76.041965] requested [1002, 1003] mapped [1002, 1003] 
> 100073 anon
> [   76.207197] 9285 (pkg-config): Uhuuh, elf segment at 1002 
> requested but the memory is mapped already
> [   76.207326] requested [1002, 1003] mapped [1002, 1003] 
> 100073 anon
> [   76.371073] 9299 (sed): Uhuuh, elf segment at 1003 requested 
> but the memory is mapped already
> [   76.371165] requested [1003, 1004] mapped [1003, 1004] 
> 100073 anon
> 
> 
> I have fixed/changed the debug patch a bit
> 
> 
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index d8c5657..a43eccaa 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -372,11 +372,35 @@ static unsigned long elf_map(struct file *filep, 
> unsigned long addr,
> } else
> map_addr = vm_mmap(filep, addr, size, prot, type, off);
> 
> -   if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr))
> +   if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr)) {
> +   struct vm_area_struct *vma;
> +   unsigned long end;
> +
> +   if (total_size)
> +   end = addr + total_size;
> +   else
> +   end = addr + size;
> +
> pr_info("%d (%s): Uhuuh, elf segment at %p requested but the 
> memory is mapped already\n",
> task_pid_nr(current), current->comm,
> (void *)addr);
> 
> +   vma = find_vma(current->mm, addr);
> +   if (vma && vma->vm_start <= addr) {
> +   pr_info("requested [%lx, %lx] mapped [%lx, %lx] %lx 
> ", addr, end,
> +   vma->vm_start, vma->vm_end, 
> vma->vm_flags);
> +   if (!vma->vm_file) {
> +   pr_cont("anon\n");
> +   } else {
> +   char path[512];
> +   char *p = file_path(vma->vm_file, path, 
> sizeof(path));
> +   if (IS_ERR(p))
> +   p = "?";
> +   pr_cont("\"%s\"\n", kbasename(p));
> +   }
> +   dump_stack();
> +   }
> +   }
> return(map_addr);
>  }
> 
> 
> 

-- 
Michal Hocko
SUSE Labs

Re: WARNING in ion_ioctl

[Dmitry Vyukov]

On Thu, Jan 4, 2018 at 3:24 PM, Greg KH  wrote:
>> > On Thu, Jan 04, 2018 at 05:57:01AM -0800, syzbot wrote:
>> >> Hello,
>> >>
>> >> syzkaller hit the following crash on
>> >> 71ee203389f7cb1c1927eab22b95baa01405791c
>> >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> >> compiler: gcc (GCC) 7.1.1 20170620
>> >> .config is attached
>> >> Raw console output is attached.
>> >> C reproducer is attached
>> >> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> >> for information about syzkaller reproducers
>> >>
>> >>
>> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> >> Reported-by: syzbot+fa2d5f63ee5904a01...@syzkaller.appspotmail.com
>> >> It will help syzbot understand when the bug is fixed. See footer for
>> >> details.
>> >> If you forward the report, please keep this part and the footer.
>> >>
>> >> audit: type=1400 audit(1514734723.062:7): avc:  denied  { map } for
>> >> pid=3502 comm="syzkaller809746" path="/root/syzkaller809746698" dev="sda1"
>> >> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> >> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
>> >> WARNING: CPU: 0 PID: 3502 at drivers/staging/android/ion/ion-ioctl.c:73
>> >> ion_ioctl+0x2db/0x380 drivers/staging/android/ion/ion-ioctl.c:73
>> >> Kernel panic - not syncing: panic_on_warn set ...
>> >
>> > This is to be expected when you pass in a crappy ion ioctl structure.
>> >
>> > So don't do that :)
>> >
>> > Yeah, it's a harsh warning, but I think the userspace developers like it
>> > to ensure they got their implementation correct.
>> >
>> > After the warning is thrown, all keeps working just fine.
>>
>> Hi Greg,
>>
>> Or, don't do WARNINGs on EINVAL and do pr_warn instead, as useful but
>> also enables automated kernel testing with non-tainted reports, which
>> is kinda a useful property.
>
> Sure, that would be the sane thing to do, but this is staging android
> code, the exact opposite of "sane" at the moment :)

If it's so bad that it's not even ready for testing and has lots of
know bugs, then I will just go and disable it on syzbot. Just say.
But then it will never become production-ready until we re-enable
testing and go through this cleaning process later.

But I would expect that if the code is in mainline, even if in
staging, we should productionize it as quickly as possible, in
particular using fuzzing as guidance.
And in the end pr_warn can even provide a more informative error
message as compared to the WARNING with cpu number, process id,
register values and the stack trace with is always the same for the
ioctl.

Re: [PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution

[Greg KH]

On Sat, Jan 06, 2018 at 09:41:17AM -0800, Dan Williams wrote:
> On Sat, Jan 6, 2018 at 1:40 AM, Greg KH  wrote:
> > On Sat, Jan 06, 2018 at 10:09:07AM +0100, Greg KH wrote:
> >> On Fri, Jan 05, 2018 at 05:10:32PM -0800, Dan Williams wrote:
> >> > Static analysis reports that 'index' may be a user controlled value that
> >> > is used as a data dependency to read 'pin' from the
> >> > 'selector->baSourceID' array. In order to avoid potential leaks of
> >> > kernel memory values, block speculative execution of the instruction
> >> > stream that could issue reads based on an invalid value of 'pin'.
> >> >
> >> > Based on an original patch by Elena Reshetova.
> >> >
> >> > Cc: Laurent Pinchart 
> >> > Cc: Mauro Carvalho Chehab 
> >> > Cc: linux-me...@vger.kernel.org
> >> > Signed-off-by: Elena Reshetova 
> >> > Signed-off-by: Dan Williams 
> >> > ---
> >> >  drivers/media/usb/uvc/uvc_v4l2.c |7 +--
> >> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> >> > b/drivers/media/usb/uvc/uvc_v4l2.c
> >> > index 3e7e283a44a8..7442626dc20e 100644
> >> > --- a/drivers/media/usb/uvc/uvc_v4l2.c
> >> > +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> >> > @@ -22,6 +22,7 @@
> >> >  #include 
> >> >  #include 
> >> >  #include 
> >> > +#include 
> >> >
> >> >  #include 
> >> >  #include 
> >> > @@ -810,6 +811,7 @@ static int uvc_ioctl_enum_input(struct file *file, 
> >> > void *fh,
> >> > struct uvc_entity *iterm = NULL;
> >> > u32 index = input->index;
> >> > int pin = 0;
> >> > +   __u8 *elem;
> >> >
> >> > if (selector == NULL ||
> >> > (chain->dev->quirks & UVC_QUIRK_IGNORE_SELECTOR_UNIT)) {
> >> > @@ -820,8 +822,9 @@ static int uvc_ioctl_enum_input(struct file *file, 
> >> > void *fh,
> >> > break;
> >> > }
> >> > pin = iterm->id;
> >> > -   } else if (index < selector->bNrInPins) {
> >> > -   pin = selector->baSourceID[index];
> >> > +   } else if ((elem = nospec_array_ptr(selector->baSourceID, index,
> >> > +   selector->bNrInPins))) {
> >> > +   pin = *elem;
> >>
> >> I dug through this before, and I couldn't find where index came from
> >> userspace, I think seeing the coverity rule would be nice.
> >
> > Ok, I take it back, this looks correct.  Ugh, the v4l ioctl api is
> > crazy complex (rightfully so), it's amazing that coverity could navigate
> > that whole thing :)
> >
> > While I'm all for fixing this type of thing, I feel like we need to do
> > something "else" for this as playing whack-a-mole for this pattern is
> > going to be a never-ending battle for all drivers for forever.  Either
> > we need some way to mark this data path to make it easy for tools like
> > sparse to flag easily, or we need to catch the issue in the driver
> > subsystems, which unfortunatly, would harm the drivers that don't have
> > this type of issue (like here.)
> >
> > I'm guessing that other operating systems, which don't have the luxury
> > of auditing all of their drivers are going for the "big hammer in the
> > subsystem" type of fix, right?
> >
> > I don't have a good answer for this, but if there was some better way to
> > rewrite these types of patterns to just prevent the need for the
> > nospec_array_ptr() type thing, that might be the best overall for
> > everyone.  Much like ebpf did with their changes.  That way a simple
> > coccinelle rule would be able to catch the pattern and rewrite it.
> >
> > Or am I just dreaming?
> 
> At least on the coccinelle front you're dreaming. Julia already took a
> look and said:
> 
> "I don't think Coccinelle would be good for doing this (ie
> implementing taint analysis) because the dataflow is too complicated."

Sorry for the confusion, no, I don't mean the "taint tracking", I mean
the generic pattern of "speculative out of bounds access" that we are
fixing here.

Yes, as you mentioned before, there are tons of false-positives in the
tree, as to find the real problems you have to show that userspace
controls the access index.  But if we have a generic pattern that can
rewrite that type of logic into one where it does not matter at all
(i.e. like the ebpf proposed changes), then it would not be an issue if
they are false or not, we just rewrite them all to be safe.

We need to find some way not only to fix these issues now (like you are
doing with this series), but to prevent them from every coming back into
the codebase again.  It's that second part that we need to keep in the
back of our minds here, while doing the first portion of this work.

> Perhaps the Coverity instance Dave mentioned at Ksummit 2012 has a
> role to play here?

We have a coverity instance that all kernel developers have access to
(just sign up and we grant it.)  We have at least one person working
full time on fixing up errors that this instance reports.  So if we
could get those rules added (which is why I asked for them), it wo

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

[Greg Kroah-Hartman]

On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote:
> On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote:
> > 4.14-stable review patch.  If anyone has any objections, please let me know.
> 
> FYI, this broke kdump, or rather the makedumpfile part thereof.
>  Forward looking wreckage is par for the kdump course, but...

Is it also broken in Linus's tree with this patch?  Or is there an
add-on patch that I should apply to 4.14 to resolve this issue there?

thanks,

greg k-h

Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs

[Avi Kivity]

On 01/06/2018 10:24 PM, Willy Tarreau wrote:

Hi Avi,

On Sat, Jan 06, 2018 at 09:33:28PM +0200, Avi Kivity wrote:

Meltdown and Spectre mitigations focus on protecting the kernel from a
hostile userspace. However, it's not a given that the kernel is the most
important target in the system. It is common in server workloads that a
single userspace application contains the valuable data on a system, and if
it were hostile, the game would already be over, without the need to
compromise the kernel.

In these workloads, a single application performs most system calls, and so
it pays the cost of protection, without benefiting from it directly (since
it is the target, rather than the kernel).

Definitely :-)


I propose to create a new capability, CAP_PAYLOAD, that allows the system
administrator to designate an application as the main workload in that
system. Other processes (like sshd or monitoring daemons) exist to support
it, and so it makes sense to protect the rest of the system from their being
compromised.

Initially I was thinking about letting applications disable PTI using
prctl() when running under a certain capability (I initially thought
about CAP_SYSADMIN though I changed my mind). One advantage of
proceeding like this is that it would have to be explicitly implemented
in the application, which limits the risk of running by default.

I later thought that we could use CAP_RAWIO for this, given that such
processes already have access to the hardware anyway. We could even
imagine not switching the page tables on such a capability without
requiring prctl(), though it would mean that processes running as root
(as is often found on a number of servers) would automatically present
a risk for the system. But maybe CAP_RAWIO + prctl() could be a good
solution.


CAP_RAWIO is like CAP_PAYLOAD in that both allow you to read stuff you 
shouldn't have access to on a vulnerable CPU. But CAP_PAYLOAD won't give 
you that access on a non-vulnerable CPU, so it's safer.


The advantage of not requiring prctl() is that it will work on 
unmodified applications, requiring only sysadmin intervention (and it's 
the sysadmin's role to designate an application as payload, not the 
application's).




I'm interested in participating to working on such a solution, given
that haproxy is severely impacted by "pti=on" and that for now we'll
have to run with "pti=off" on the whole system until a more suitable
solution is found.

I'd rather not rush anything and let things calm down for a while to
avoid adding disturbance to the current situation. But I'm willing to
continue this discussion and even test patches.




Then you might want to test 
https://www.spinics.net/lists/kernel/msg2689101.html and its companion 
patchset https://www.spinics.net/lists/kernel/msg2689134.html, which as 
a side effect significantly reduce KPTI impact on C10K applications (and 
as their main effect improve their performance).

Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs

[Avi Kivity]

On 01/06/2018 10:02 PM, Alan Cox wrote:

I propose to create a new capability, CAP_PAYLOAD, that allows the
system administrator to designate an application as the main workload in
that system. Other processes (like sshd or monitoring daemons) exist to
support it, and so it makes sense to protect the rest of the system from
their being compromised.

Much more general would be to do this with cgroups both for group-group
trust and group-kernel trust levels.



I think capabilities will work just as well with cgroups. The container 
manager will set CAP_PAYLOAD to payload containers; and if those run an 
init system or a container manager themselves, they'll drop CAP_PAYLOAD 
for all process/sub-containers but their payloads.

[PATCH] KVM: PPC: Use seq_puts() in kvmppc_exit_timing_show()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 7 Jan 2018 10:07:36 +0100

A headline should be quickly put into a sequence. Thus use the
function "seq_puts" instead of "seq_printf" for this purpose.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 arch/powerpc/kvm/timing.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/kvm/timing.c b/arch/powerpc/kvm/timing.c
index e44d2b2ea97e..1c03c978eb18 100644
--- a/arch/powerpc/kvm/timing.c
+++ b/arch/powerpc/kvm/timing.c
@@ -143,8 +143,7 @@ static int kvmppc_exit_timing_show(struct seq_file *m, void 
*private)
int i;
u64 min, max, sum, sum_quad;
 
-   seq_printf(m, "%s", "type   count   min max sum 
sum_squared\n");
-
+   seq_puts(m, "type   count   min max sum sum_squared\n");
 
for (i = 0; i < __NUMBER_OF_KVM_EXIT_TYPES; i++) {
 
-- 
2.15.1

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

[Mike Galbraith]

On Sun, 2018-01-07 at 10:11 +0100, Greg Kroah-Hartman wrote:
> On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote:
> > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote:
> > > 4.14-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > 
> > FYI, this broke kdump, or rather the makedumpfile part thereof.
> >  Forward looking wreckage is par for the kdump course, but...
> 
> Is it also broken in Linus's tree with this patch?  Or is there an
> add-on patch that I should apply to 4.14 to resolve this issue there?

Yeah, it's belly up.  By its very nature, it's gonna get dinged up
regularly.  I only mentioned it because it's not expected that stuff
gets dinged up retroactively.

-Mike

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

[David Woodhouse]

On Sat, 2018-01-06 at 18:02 +0100, Borislav Petkov wrote:
> On Sat, Jan 06, 2018 at 08:23:21AM +, David Woodhouse wrote:
> > Thanks. From code inspection, I couldn't see that it was smart enough
> > *not* to process a relative jump in the 'altinstr' section which was
> > jumping to a target *within* that same altinstr section, and thus
> > didn't need to be touched at all. Does this work?
> > 
> > alternative("", "xor %%rdi, %%rdi; jmp 2f; 2: jmp startup_64", 
> > X86_FEATURE_K8);
> 
> So this is fine because it gets turned into a two-byte jump:
> 
> [    0.816005] apply_alternatives: feat: 3*32+4, old: (810273c9, len: 
> 10), repl: (824759d2, len: 10), pad: 10
> [    0.820001] 810273c9: old_insn: 90 90 90 90 90 90 90 90 90 90
> [    0.821247] 824759d2: rpl_insn: 48 31 ff eb 00 e9 24 a6 b8 fe
> [    0.822455] process_jumps: insn start 0x48, at 0, len: 3
> [    0.823496] process_jumps: insn start 0xeb, at 3, len: 2
> [    0.824002] process_jumps: insn start 0xe9, at 5, len: 5
> [    0.825120] recompute_jump: target RIP: 8100, new_displ: 
> 0xfffd8c37
> [    0.826567] recompute_jump: final displ: 0xfffd8c32, JMP 0x8100
> [    0.828001] 810273c9: final_insn: e9 32 8c fd ff e9 24 a6 b8 fe
> 
> i.e., notice the "eb 00" thing.
> 
> Which, when copied into the kernel proper, will simply work as it is
> a small offset which, when referring to other code which gets copied
> *together* with it, should work. I.e., we're not changing the offsets
> during the copy so all good.
> 
> It becomes more tricky when you force a 5-byte jump:
> 
>     alternative("", "xor %%rdi, %%rdi; .byte 0xe9; .long 2f - 
> .altinstr_replacement; 2: jmp startup_64", X86_FEATURE_K8);
> 
> because then you need to know whether the offset is within the
> .altinstr_replacement section itself or it is meant to be an absolute
> offset like jmp startup_64 or within another section.

Right, so it all tends to work out OK purely by virtue of the fact that
oldinstr and altinstr end up far enough apart in the image that they're
5-byte jumps. Which isn't perfect but we've lived with worse.

I'm relatively pleased that we've managed to eliminate this as a
dependency for inverting the X86_FEATURE_RETPOLINE logic though, by
following Linus' suggestion to just emit the thunk inline instead of
calling the same one as GCC.

The other fun one for alternatives is in entry_64.S, where we really
need the return address of the call instruction to be *precisely* the 
.Lentry_SYSCALL_64_after_fastpath_call label, so we have to eschew the
normal NOSPEC_CALL there:

/*
 * This call instruction is handled specially in stub_ptregs_64.
 * It might end up jumping to the slow path.  If it jumps, RAX
 * and all argument registers are clobbered.
 */
#ifdef CONFIG_RETPOLINE
movqsys_call_table(, %rax, 8), %rax
call__x86.indirect_thunk.rax
#else
call*sys_call_table(, %rax, 8)
#endif
.Lentry_SYSCALL_64_after_fastpath_call:

Now it's not like an unconditional branch to the out-of-line thunk is
really going to be much of a problem, even in the case where that out-
of-line thunk is alternative'd into a bare 'jmp *%rax'. But it would be
slightly nicer to avoid it.

At the moment though, it's really hard to ensure that the 'call'
instruction that leaves its address on the stack is right at the end.

Am I missing a trick there, other than manually inserting leading NOPs
(instead of the automatic trailing ones) to ensure that everything
lines up, and making assumptions about how the assembler will encode
instructions (not that it has *much* choice, but it has some).

On the whole I think it's fine as it is, but if you have a simple fix
then that would be nice.


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] x86/mm/pti: remove dead logic during user pagetable population

[Thomas Gleixner]

On Sun, 7 Jan 2018, Jike Song wrote:
> On Sun, Jan 7, 2018 at 3:33 AM, Thomas Gleixner  wrote:
> > On Sun, 7 Jan 2018, Jike Song wrote:
> >
> > Care to explain why you think this is not needed?
> >
> 
> Hi Thomas,
> 
> Look at one of the original code snippets:
> 
> 162 if (pgd_none(*pgd)) {
> 163 unsigned long new_p4d_page = __get_free_page(gfp);
> 164 if (!new_p4d_page)
> 165 return NULL;
> 166
> 167 if (pgd_none(*pgd)) {
> 168 set_pgd(pgd, __pgd(_KERNPG_TABLE |
> __pa(new_p4d_page)));
> 169 new_p4d_page = 0;
> 170 }
> 171 if (new_p4d_page)
> 172 free_page(new_p4d_page);
> 173 }
> 
> Correct me if I'm too dumb to see the rationale here, but to me there
> can't be any difference between
> two pgd_none(*pgd) of L162 and L167, so it is always false in L171.

Right, but this kind of explanation wants to be in the changelog. Empty
changelogs for this kind of change are just not acceptable.

Thanks,

tglx

Re: [PATCH 3/7] ARM: dts: imx6ull: add additional pinfunc defines for i.MX 6ULL

[Stefan Agner]

On 2018-01-05 17:49, Rob Herring wrote:
> On Tue, Jan 02, 2018 at 05:42:19PM +0100, Stefan Agner wrote:
>> From: Bai Ping 
>>
>> On i.MX 6ULL, the pin MUX and CTRL register of BOOT_MODEx and TAMPERx
>> pins are available through IOMUXC_SNVS. Add additional pinfunc defines.
>>
>> Signed-off-by: Bai Ping 
>> Signed-off-by: Stefan Agner 
>> ---
>>  arch/arm/boot/dts/imx6ull-pinfunc-snvs.h | 29 +
>>  arch/arm/boot/dts/imx6ull.dtsi   |  1 +
>>  2 files changed, 30 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc-snvs.h
>>
>> diff --git a/arch/arm/boot/dts/imx6ull-pinfunc-snvs.h 
>> b/arch/arm/boot/dts/imx6ull-pinfunc-snvs.h
>> new file mode 100644
>> index ..da3f412e4269
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/imx6ull-pinfunc-snvs.h
>> @@ -0,0 +1,29 @@
>> +/*
>> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> 
> It's 2018 now.
> 

I don't think you are supposed to chance copyright year unless you
change it significantly.

At least that article suggests so:
https://www.copyrightlaws.com/copyright-notice-year/

I took that patch from the downstream NXP kernel, so I guess 2016 was
the year of first publication...

>> + *
>> + * 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.
> 
> Use SPDX. With that,

Agreed.

> 
> Reviewed-by: Rob Herring 

--
Stefan

Re: [PATCH] ARM: dts: exynos: fix RTC interrupt for exynos5410

[Krzysztof Kozlowski]

On Thu, Dec 21, 2017 at 10:30:07PM +0100, Arnd Bergmann wrote:
> According to the comment added to exynos_dt_pmu_match[] in commit
> 8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"),
> the RTC is not able to wake up the system through the PMU on Exynos5410,
> unlike Exynos5420.
> 
> However, when the RTC DT node got added, it was a straight copy of
> the Exynos5420 node, which now causes a warning from dtc.
> 
> This removes the incorrect interrupt-parent, which should get the
> interrupt working and avoid the warning.
> 
> Fixes: e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410")
> Signed-off-by: Arnd Bergmann 
> ---
>  arch/arm/boot/dts/exynos5410.dtsi | 1 -
>  1 file changed, 1 deletion(-)
>

I reverted my commit [1] and applied yours. What is interesting... RTC
works fine in any combination (so even routing interrupts through
non-interrupt-controller PMU).

Best regards,
Krzysztof


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git/commit/?h=next/dt&id=6737b081409a4373e9d02c75aea7b916481e31b5

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

[Thomas Gleixner]

On Sat, 6 Jan 2018, Alexei Starovoitov wrote:
> which clearly states that bpf_tail_call() was used in the attack.
> Yet none of the intel nor arm patches address speculation in
> this bpf helper!
> It means that:
> - gpz didn't share neither exploit nor the detailed description
>   of the POC with cpu vendors until now
> - coverity rules used to find all these places in the kernel
>   failed to find bpf_tail_call
> - cpu vendors were speculating what variant 1 can actually do

You forgot to mention that there might be other attacks than the public POC
which are not covered by a simple AND 

Thanks,

tglx

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

[Mauro Carvalho Chehab]

Em Fri, 05 Jan 2018 20:41:41 +0100
Knut Omang  escreveu:

> On Fri, 2018-01-05 at 16:08 -0200, Mauro Carvalho Chehab wrote:
> > Em Thu, 04 Jan 2018 21:15:31 +0100
> > Knut Omang  escreveu:
> >   
> > > > I'm surprised the commit message and the provided documentation say
> > > > nothing about using CHECK=foo on the command line. That already supports
> > > > arbitrary checkers. 
> > > 
> > > The problem, highlighted by Jim Davis in
> > > 
> > > https://lkml.org/lkml/2017/11/20/638
> > > 
> > > is that the current solution isn't flexible enough - that discussion 
> > > is what lead me to this reimplementation of what I originally intended 
> > > to be a checkpatch only solution.
> > >   
> > > > How does this relate to that? Is this supposed to be
> > > > a complete replacement? Or what?
> > > 
> > > It has evolved into a complete replacement of the intention of CHECK.
> > >   
> > > > 'make help' also references $CHECK, and this patch doesn't update the
> > > > help text.
> > > 
> > > I realize now that this needs to be handled in some way due to the way I 
> > > split the 
> > > arguments with '--' - the intention was to keep it for bw compatibility.
> > > 
> > > It would be good to know if people rely on using CHECK with C={1,2} for 
> > > anything beside the checkers supported by runchecks today  
> > 
> > I do. Here, I use:
> > 
> > $ make ARCH=i386  CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 
> > W=1
> > CHECK='compile_checks' M=drivers/media
> > 
> > Where "compile_checks" is actually a small script that calls both
> > smatch and sparse:
> > 
> > #!/bin/bash
> > /devel/smatch/smatch -p=kernel $@  
> 
> I suppose you here refer to this:
> https://blogs.oracle.com/linuxkernel/smatch-static-analysis-tool-overview,-by-dan-carpenter
> 
> Good idea! I'll have a look at how that plays with this.

Yes.

> 
> > /devel/sparse/sparse $@
> > 
> > So, I'm not sure why we need something else.   
> 
> The core functionality is the selective suppression logic and output 
> unification
> which makes checking with automated build tools more flexible and 
> applicable right away (not when every warning from every checker is fixed...)

If the idea is to use it only/mostly with automated build tools, then
the better would be to call it only when explicitly requested, e. g.
something like C=3, in order to avoid breaking the usecase where one
would run its own script.

On my case, I use C=1 CHECK=compile_checks as part as my usual patch
handling. For every patch I apply on media, I call make again, to be
sure that no warning/building errors were added, not only with gcc
but also with smatch and sparse. 

> 
> > That said, I didn't look
> > on its code, but looking on its diffstat:
> > 
> >  Makefile   |  23 +-
> >  scripts/Makefile.build |   4 +-
> >  scripts/runchecks  | 734 ++-
> >  scripts/runchecks.cfg  |  63 ++-
> >  scripts/runchecks_help.txt |  43 ++-
> > 
> > Using a 734 lines python program just to do an exec on an external checker
> > seems too much!  
> 
> Sure, if that was the case I would be the first to agree :-)
> 
> Thanks,
> Knut
> 
> > Thanks,
> > Mauro  



Thanks,
Mauro

Re: [PATCH v2 01/27] staging: ccree: SPDXify driver

[Gilad Ben-Yossef]

On Wed, Jan 3, 2018 at 5:01 PM, Philippe Ombredanne
 wrote:
> Gilad,
>
> On Wed, Jan 3, 2018 at 2:35 PM, Gilad Ben-Yossef  wrote:
>> Replace verbatim GPL v2 copy with SPDX tag.
>>
>> Signed-off-by: Gilad Ben-Yossef 
>
> 
>
>> --- a/drivers/staging/ccree/cc_crypto_ctx.h
>> +++ b/drivers/staging/ccree/cc_crypto_ctx.h
>> @@ -1,18 +1,5 @@
>> -/*
>> - * Copyright (C) 2012-2017 ARM Limited or its affiliates.
>> - *
>> - * 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.
>> - *
>> - * This program is distributed in the hope that it will be useful,
>> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> - * GNU General Public License for more details.
>> - *
>> - * You should have received a copy of the GNU General Public License
>> - * along with this program; if not, see .
>> - */
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
>
> Thank you for using the SPDX tags!
>
> Now, while I appreciate your attempt to use the latest and greatest
> SPDX license id definitions (published by SPDX a few days agao), THIS
> IS NOT a welcomed initiative. Please stick instead to use ONLY the
> SPDX license ids that are defined in Thomas doc patches [1]: e.g. use
> instead:  SPDX-License-Identifier: GPL-2.0 and please DO NOT USE
> GPL-2.0-only for now.

Oh dear. It seems I have been over enthusiastic with this.
I shall post a revised  patch set. Sorry for the noise.

>
> The rationale is simple: from a kernel standpoint we cannot depend on
> the latest changes of an external spec such as SPDX (and I am involved
> with SPDX alright but I am wearing a kernel hat here). This is why
> things have been carefully documented for the kernel proper by Thomas.
> It is perfectly fine at some times in the future to adopt the newest
> license ids, but this will have to happen in an orderly fashion with a
> proper doc update and the eventual tree-wide changes to update every
> occurrence. This cannot happen any other way or this would defeat the
> whole purpose to have clear licensing kernel-wide: using the latest
> and greatest introduces variations and creates a mess that we want to
> avoid in the first place.
>
> CC: Thomas Gleixner 
>
> [1] https://lkml.org/lkml/2017/12/28/323
>

Just a thought - it might be useful to have an SPDX revision as part of the tag,
e.g.

SPDX-3.0-License-Identifier: GPL-2.0-only

It seems it will make transitions such as this easier, me thinks.

Maybe something to consider for SPDX 3.1 :-)

Thanks,
Gilad



-- 
Gilad Ben-Yossef
Chief Coffee Drinker

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

Re: [PATCH v4 00/14] Modernization and fixes for NuBus subsystem

[Geert Uytterhoeven]

Hi Finn,

On Sat, Jan 6, 2018 at 4:34 AM, Finn Thain  wrote:
> On Fri, 5 Jan 2018, Geert Uytterhoeven wrote:
>> I assume you meant this to go in through the m68k tree?
>
> Yes, please. Because the NuBus-PowerMac port is out-of-tree, the m68k tree
> seems more appropriate than the powerpc tree for this submission.

OK.

>> Can you please run this through checkpatch, and fix the reported white
>> space and other real (some are false positives) issues?
>
> Checkpatch is great but it is also incredibly noisy. So I missed a long
> line that should have been wrapped in patch 4/14 and another in 5/14.
> Sorry about that.
>
> Checkpatch said, "Symbolic permissions are not preferred". But I didn't
> find any advice in the style guide, so I just retained the existing code
> style. What is your preference here?

If you add new users, please use octal permissions, as they're easier to read.
If you just move code, keep it like it is. You may want to add an additional
patch to convert from symbolic to octal permissions, though.

> Checkpatch also said, "code indent should use tabs where possible" though
> I've used only tabs to indent (according to scope, of course). Checkpatch
> also says, "please, no spaces at the start of a line". Yet it is common
> practice to put spaces at the start of a continuation (after any
> indentation tabs, of course) when wrapping lines*. Please let me know your
> preference.

Checkpatch does not complain when padding TABs with a few spaces to make
continuations match the previous line. it does complain when using spaces only
("please, no spaces at the _start_ of a line").

> Checkpatch asked, "added, moved or deleted file(s), does MAINTAINERS need
> updating?" Regarding drivers/nubus/*, that question is not a new one. The
> issue can be addressed in this patch or an earlier one, so as to keep
> checkpatch happy, or it can be addressed in a separate submission... Do we
> bring drivers/nubus/* under the Mac 68k subsystem? Isn't it a subsystem
> itself? (If maintain that code, do I get to exercise my discretion
> regarding checkpatch limitations?)

That's just a question. Do you want to assume maintainership for nubus?

> The rest of the checkpatch output seems to be irrelevant (or am I missing
> something?) --
>
> Macros with complex values should be enclosed in parentheses
>
> trailing statements should be on next line
>
> Possible unwrapped commit description
>
> braces {} are not necessary for single statement blocks
>
> file is marked as 'obsolete' in the MAINTAINERS hierarchy.  No
> unnecessary modifications please.
>
> suspect code indent for conditional statements
>
> Please let me know how you would like me to address these issues, and I'll
> re-submit.

Most (all?) of these are indeed false positives.

> * IMO checkpatch is really good at certain things but line wrap isn't one
> of them. The git project's Documentation/CodingGuidelines seems to be a
> better description of Linux development practice than checkpatch's regexps:
>
>There are two schools of thought when it comes to splitting a long
>logical line into multiple lines.  Some people push the second and
>subsequent lines far enough to the right with tabs and align them:
>
> if (the_beginning_of_a_very_long_expression_that_has_to ||
> span_more_than_a_single_line_of ||
> the_source_text) {
> ...
>
>while other people prefer to align the second and the subsequent
>lines with the column immediately inside the opening parenthesis,
>with tabs and spaces, following our "tabstop is always a multiple
>of 8" convention:
>
> if (the_beginning_of_a_very_long_expression_that_has_to ||
> span_more_than_a_single_line_of ||
> the_source_text) {
> ...
>
>Both are valid, and we use both.  Again, just do not mix styles in
>the same part of the code and mimic existing styles in the
>neighbourhood.

And both are accepted by checkpatch. So if it does warn, check your TABs
and spaces again.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] Revert "ARM: dts: exynos: Add missing interrupt-controller properties to Exynos5410 PMU"

[Krzysztof Kozlowski]

This reverts commit 6737b081409a4373e9d02c75aea7b916481e31b5.

Unlike on Exynos5420-family, on Exynos5410 the PMU is not an interrupt
controller so it should not handle interrupts of RTC.  The DTC warning
(addressed by mentioned commit) should be fixed by not routing RTC
interrupts to PMU.

Reported-by: Arnd Bergmann 
Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos5410.dtsi | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
b/arch/arm/boot/dts/exynos5410.dtsi
index 375b73015ee4..83641ad0d8f2 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -72,9 +72,6 @@
clock-names = "clkout16";
clocks = <&fin_pll>;
#clock-cells = <1>;
-   interrupt-controller;
-   #interrupt-cells = <3>;
-   interrupt-parent = <&gic>;
};
 
clock: clock-controller@1001 {
-- 
2.11.0

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

[Michal Hocko]

On Sun 07-01-18 10:11:15, Greg KH wrote:
> On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote:
> > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote:
> > > 4.14-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > 
> > FYI, this broke kdump, or rather the makedumpfile part thereof.
> >  Forward looking wreckage is par for the kdump course, but...
> 
> Is it also broken in Linus's tree with this patch?  Or is there an
> add-on patch that I should apply to 4.14 to resolve this issue there?

This one 
http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com
I guess.

-- 
Michal Hocko
SUSE Labs

Feedback on 4.9 performance after PTI fixes

[Willy Tarreau]

Hi,

I managed to take a bit of time to run some more tests on PTI both
native and hosted in KVM, on stable versions built with
CONFIG_PAGE_TABLE_ISOLATION=y. Here it's 4.9.75, used both on the
host and the VM. I could compare pti=on/off both in the host and the
VM. A single CPU was exposed in the VM.

It was running on my laptop (core i7 3320M at 2.6 GHz, 3.3 GHz single
core turbo).

The test was run on haproxy's ability to forward connections. The
results are below :

   Host  |  Guest  | conn/s  | ratio_to_host |  ratio_to_VM | Notes
-+-+-+---+--+
 pti=off |   - |  27400  | 100.0%|  -   | host reference
 pti=off | pti=off |  24200  |  88.3%|100.0%| VM reference 
 pti=off | pti=on  |  13300  |  48.5%| 55.0%|
 pti=on  |   - |  23800  |  86.9%|  -   | protected host
 pti=on  | pti=off |  23100  |  84.3%| 95.5%|
 pti=on  | pti=on  |  13300  |  48.5%| 55.0%|

The ratio_to_host column shows the performance relative to the host
with pti=off. The ratio_to_VM column shows the performance relative to
the VM running with pti=off in a host also having pti=off (ie:
performance before upgrading the systems).

On this test we see a few things :
  - the performance impact on the native host is around 13%

  - the highest performance impact on VMs comes from having PTI on the
guest kernel (-45%). At this point it makes no difference whether
the host kernel has it or not.

  - the host kernel's protection has a very limited impact on the guest
system's performance (-4.5%), which is probably nice for some cloud
users who might want to take the risk of turning the protection off
on their VMs.

The impact inside VMs is quite big but it's not where we usuall install
processes sensitive to syscall performance. I could find an even higher
impact on a packet generation program dropping from 2.5 Mpps to 600kpps
in the VM after the fix, but it doesn't make much sense to do this in
VMs so I don't really care.

I have not yet tried the retpoline patches.

Regards,
Willy

Re: [RFCv2 2/4] Documentation: document nospec helpers

[Geert Uytterhoeven]

Hi Mark,

On Fri, Jan 5, 2018 at 3:57 PM, Mark Rutland  wrote:
> Document the rationale and usage of the new nospec*() helpers.
>
> Signed-off-by: Mark Rutland 
> Signed-off-by: Will Deacon 
> Cc: Dan Williams 
> Cc: Jonathan Corbet 
> Cc: Peter Zijlstra 

I love your patch! Yet something to improve:
(borrowed from another Intel division)

> --- /dev/null
> +++ b/Documentation/speculation.txt
> @@ -0,0 +1,166 @@
> +This document explains potential effects of speculation, and how undesirable
> +effects can be mitigated portably using common APIs.
> +
> +===
> +Speculation
> +===
> +
> +To improve performance and minimize average latencies, many contemporary CPUs
> +employ speculative execution techniques such as branch prediction, performing
> +work which may be discarded at a later stage.
> +
> +Typically speculative execution cannot be observed from architectural state,
> +such as the contents of registers. However, in some cases it is possible to
> +observe its impact on microarchitectural state, such as the presence or
> +absence of data in caches. Such state may form side-channels which can be
> +observed to extract secret information.
> +
> +For example, in the presence of branch prediction, it is possible for bounds
> +checks to be ignored by code which is speculatively executed. Consider the
> +following code:
> +
> +   int load_array(int *array, unsigned int idx) {

"{" on next line?

> +   if (idx >= MAX_ARRAY_ELEMS)
> +   return 0;
> +   else
> +   return array[idx];
> +   }
> +
> +Which, on arm64, may be compiled to an assembly sequence such as:
> +
> +   CMP , #MAX_ARRAY_ELEMS
> +   B.LTless
> +   MOV , #0
> +   RET
> +  less:
> +   LDR , [, ]
> +   RET
> +
> +It is possible that a CPU mis-predicts the conditional branch, and
> +speculatively loads array[idx], even if idx >= MAX_ARRAY_ELEMS. This value
> +will subsequently be discarded, but the speculated load may affect
> +microarchitectural state which can be subsequently measured.
> +
> +More complex sequences involving multiple dependent memory accesses may 
> result
> +in sensitive information being leaked. Consider the following code, building 
> on
> +the prior example:
> +
> +   int load_dependent_arrays(int *arr1, int *arr2, int idx) {

"{" on next line

> +   int val1, val2,
> +
> +   val1 = load_array(arr1, idx);
> +   val2 = load_array(arr2, val1);
> +
> +   return val2;
> +   }
> +
> +Under speculation, the first call to load_array() may return the value of an
> +out-of-bounds address, while the second call will influence 
> microarchitectural
> +state dependent on this value. This may provide an arbitrary read primitive.
> +
> +
> +Mitigating speculation side-channels
> +
> +
> +The kernel provides a generic API to ensure that bounds checks are respected
> +even under speculation. Architectures which are affected by speculation-based
> +side-channels are expected to implement these primitives.
> +
> +The following helpers found in  can be used to prevent
> +information from being leaked via side-channels.
> +
> +* nospec_ptr(ptr, lo, hi)
> +
> +  Returns a sanitized pointer that is bounded by the [lo, hi) interval. When
> +  ptr < lo, or ptr >= hi, NULL is returned. Prevents an out-of-bounds pointer
> +  being propagated to code which is speculatively executed.
> +
> +  This is expected to be used by code which computes pointers to data
> +  structures, where part of the address (such as an array index) may be
> +  user-controlled.
> +
> +  This can be used to protect the earlier load_array() example:
> +
> +  int load_array(int *array, unsigned int idx)
> +  {
> +   int *elem;
> +
> +   if ((elem = nospec_ptr(array + idx, array, array + MAX_ARRAY_ELEMS)))

elem = nospec_ptr(array + idx, array, array + MAX_ARRAY_ELEMS);
if (elem)

> +   return *elem;
> +   else
> +   return 0;
> +  }
> +
> +  This can also be used in situations where multiple fields on a structure 
> are
> +  accessed:
> +
> +   struct foo array[SIZE];
> +   int a, b;
> +
> +   void do_thing(int idx)
> +   {
> +   struct foo *elem;
> +
> +   if ((elem = nospec_ptr(array + idx, array, array + SIZE)) {

elem = nospec_ptr(array + idx, array, array + SIZE;
if (elem) {

> +   a = elem->field_a;
> +   b = elem->field_b;
> +   }
> +   }
> +
> +  It is imperative that the returned pointer is used. Pointers which are
> +  generated separately are subject to a number of potential CPU and compiler
> +  optimizations, and may still be used speculatively. For example, this means
> +  that the following sequence is unsafe:
> +
> +   struct foo array[SIZE];
> +   int a, b;
> +
> +   voi

[PATCH v2] x86/mm/pti: remove dead logic during user pagetable population

[Jike Song]

Look at one of the code snippets:

162 if (pgd_none(*pgd)) {
163 unsigned long new_p4d_page = __get_free_page(gfp);
164 if (!new_p4d_page)
165 return NULL;
166
167 if (pgd_none(*pgd)) {
168 set_pgd(pgd, __pgd(_KERNPG_TABLE | __pa(new_p4d_page)));
169 new_p4d_page = 0;
170 }
171 if (new_p4d_page)
172 free_page(new_p4d_page);
173 }

There can't be any difference between two pgd_none(*pgd) at L162 and L167,
so it's always false at L171.

v2: add the commit message above.

Signed-off-by: Jike Song 
Cc: David Woodhouse 
Cc: Alan Cox 
Cc: Jiri Koshina 
Cc: Linus Torvalds 
Cc: Tim Chen 
Cc: Andi Lutomirski  
Cc: Andi Kleen 
Cc: Peter Zijlstra 
Cc: Paul Turner 
Cc: Tom Lendacky 
Cc: Greg KH 
Cc: Dave Hansen 
Cc: Kees Cook 
Cc: sta...@vger.kernel.org
Signed-off-by: Jike Song 
---
 arch/x86/mm/pti.c | 28 
 1 file changed, 4 insertions(+), 24 deletions(-)

diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index 43d4a4a29037..dc611d039bd5 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -164,12 +164,7 @@ static p4d_t *pti_user_pagetable_walk_p4d(unsigned long 
address)
if (!new_p4d_page)
return NULL;
 
-   if (pgd_none(*pgd)) {
-   set_pgd(pgd, __pgd(_KERNPG_TABLE | __pa(new_p4d_page)));
-   new_p4d_page = 0;
-   }
-   if (new_p4d_page)
-   free_page(new_p4d_page);
+   set_pgd(pgd, __pgd(_KERNPG_TABLE | __pa(new_p4d_page)));
}
BUILD_BUG_ON(pgd_large(*pgd) != 0);
 
@@ -194,12 +189,7 @@ static pmd_t *pti_user_pagetable_walk_pmd(unsigned long 
address)
if (!new_pud_page)
return NULL;
 
-   if (p4d_none(*p4d)) {
-   set_p4d(p4d, __p4d(_KERNPG_TABLE | __pa(new_pud_page)));
-   new_pud_page = 0;
-   }
-   if (new_pud_page)
-   free_page(new_pud_page);
+   set_p4d(p4d, __p4d(_KERNPG_TABLE | __pa(new_pud_page)));
}
 
pud = pud_offset(p4d, address);
@@ -213,12 +203,7 @@ static pmd_t *pti_user_pagetable_walk_pmd(unsigned long 
address)
if (!new_pmd_page)
return NULL;
 
-   if (pud_none(*pud)) {
-   set_pud(pud, __pud(_KERNPG_TABLE | __pa(new_pmd_page)));
-   new_pmd_page = 0;
-   }
-   if (new_pmd_page)
-   free_page(new_pmd_page);
+   set_pud(pud, __pud(_KERNPG_TABLE | __pa(new_pmd_page)));
}
 
return pmd_offset(pud, address);
@@ -251,12 +236,7 @@ static __init pte_t *pti_user_pagetable_walk_pte(unsigned 
long address)
if (!new_pte_page)
return NULL;
 
-   if (pmd_none(*pmd)) {
-   set_pmd(pmd, __pmd(_KERNPG_TABLE | __pa(new_pte_page)));
-   new_pte_page = 0;
-   }
-   if (new_pte_page)
-   free_page(new_pte_page);
+   set_pmd(pmd, __pmd(_KERNPG_TABLE | __pa(new_pte_page)));
}
 
pte = pte_offset_kernel(pmd, address);
-- 
2.14.3

Re: [PATCH] x86/mm/pti: remove dead logic during user pagetable population

[Jike Song]

On Sun, Jan 7, 2018 at 5:48 PM, Thomas Gleixner  wrote:
> On Sun, 7 Jan 2018, Jike Song wrote:
>> On Sun, Jan 7, 2018 at 3:33 AM, Thomas Gleixner  wrote:
>> > On Sun, 7 Jan 2018, Jike Song wrote:
>> >
>> > Care to explain why you think this is not needed?
>> >
>>
>> Hi Thomas,
>>
>> Look at one of the original code snippets:
>>
>> 162 if (pgd_none(*pgd)) {
>> 163 unsigned long new_p4d_page = __get_free_page(gfp);
>> 164 if (!new_p4d_page)
>> 165 return NULL;
>> 166
>> 167 if (pgd_none(*pgd)) {
>> 168 set_pgd(pgd, __pgd(_KERNPG_TABLE |
>> __pa(new_p4d_page)));
>> 169 new_p4d_page = 0;
>> 170 }
>> 171 if (new_p4d_page)
>> 172 free_page(new_p4d_page);
>> 173 }
>>
>> Correct me if I'm too dumb to see the rationale here, but to me there
>> can't be any difference between
>> two pgd_none(*pgd) of L162 and L167, so it is always false in L171.
>
> Right, but this kind of explanation wants to be in the changelog. Empty
> changelogs for this kind of change are just not acceptable.
>

Roger that, just sent v2 out :)

I'm not quite sure but I CCed sta...@kernel.org anyway.


> Thanks,
>
> tglx


-- 
Thanks,
Jike

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

[Greg Kroah-Hartman]

On Sun, Jan 07, 2018 at 11:18:47AM +0100, Michal Hocko wrote:
> On Sun 07-01-18 10:11:15, Greg KH wrote:
> > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote:
> > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote:
> > > > 4.14-stable review patch.  If anyone has any objections, please let me 
> > > > know.
> > > 
> > > FYI, this broke kdump, or rather the makedumpfile part thereof.
> > >  Forward looking wreckage is par for the kdump course, but...
> > 
> > Is it also broken in Linus's tree with this patch?  Or is there an
> > add-on patch that I should apply to 4.14 to resolve this issue there?
> 
> This one 
> http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com
> I guess.

Good, that patch is queued up for the next 4.14-stable release in a few
days.

thanks,

greg k-h

Re: [PATCH 4.4 00/37] 4.4.110-stable review

[Greg Kroah-Hartman]

On Fri, Jan 05, 2018 at 04:03:54PM -0500, Pavel Tatashin wrote:
> The hardware works :) I meant that before the patch linked in
> https://lkml.org/lkml/2018/1/5/534, I was never able to boot 4.4.110. But
> with that patch applied, I was able to boot it at least once, but it could
> be accidental. The hang/panic does not happen at the same time on every
> boot.

Any chance you can grab the latest SLES 12 kernel and run it with pti
and efi enabled to see if that works properly for you or not?  I trust
SUSE's testing of their kernel, and odds are I'm just missing one of
their many other patches they have in their tree for other issues that
they have seen in the past.

If you want, I can just send you the full patch that they run on top of
the latest 4.4 stable tree, so you don't have to dig it out of their git
repo if you can't find the binary image.

thanks,

greg k-h

Re: 4.15-rc6+ hang

[Christian Kujau]

On Thu, 4 Jan 2018, Tom Hromatka wrote:
> > > [0.00] [ cut here ]
> > > [0.00] XSAVE consistency problem, dumping leaves
> > I think this is a vbox issue, with virtualbox not exposing all the
> > xsave state, so that when the kernel adds up the xsave areas, the end
> > result doesn't match what the total size is reported to be.
> 
> It seems probable that this is a VirtualBox issue.  I was
> able to boot my exact 4.15-rc6+ kernel in qemu-kvm v1.5.3
> just fine.

This was discussed on vbox-dev back in May 2017 (see the whole thread for 
more details):

 https://www.virtualbox.org/pipermail/vbox-dev/2017-May/014466.html

Does that help?

Christian.
-- 
BOFH excuse #9:

doppler effect

Re: dvb usb issues since kernel 4.9

[Mauro Carvalho Chehab]

Em Sat, 6 Jan 2018 16:44:20 -0500 (EST)
Alan Stern  escreveu:

> On Sat, 6 Jan 2018, Mauro Carvalho Chehab wrote:
> 
> > Hi Josef,
> > 
> > Em Sat, 6 Jan 2018 16:04:16 +0100
> > "Josef Griebichler"  escreveu:
> >   
> > > Hi,
> > > 
> > > the causing commit has been identified.
> > > After reverting commit 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882
> > > its working again.  
> > 
> > Just replying to me won't magically fix this. The ones that were involved on
> > this patch should also be c/c, plus USB people. Just added them.
> >   
> > > Please have a look into the thread 
> > > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?pageNo=13
> > > here are several users aknowledging the revert solves their issues with 
> > > usb dvb cards.  
> > 
> > I read the entire (long) thread there. In order to make easier for the
> > others, from what I understand, the problem happens on both x86 and arm,
> > although almost all comments there are mentioning tests with raspbian
> > Kernel (with uses a different USB host driver than the upstream one).
> > 
> > It happens when watching digital TV DVB-C channels, with usually means
> > a sustained bit rate of 11 MBps to 54 MBps.
> > 
> > The reports mention the dvbsky, with uses USB URB bulk transfers.
> > On every several minutes (5 to 10 mins), the stream suffer "glitches"
> > caused by frame losses.
> > 
> > The part of the thread that contains the bisect is at:
> > 
> > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965
> > 
> > It indirectly mentions another comment on the thread with points
> > to:
> > https://github.com/raspberrypi/linux/issues/2134
> > 
> > There, it says that this fix part of the issues:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f41c0316ed52b0b44542491d89278efdaa70e4
> > 
> > but it affects URB packet losses on a lesser extend.
> > 
> > The main issue is really the logic changes a the core softirq logic.
> > 
> > Using Kernel 4.14.10 on a Raspberry Pi 3 with 4cd13c2 commit reverted
> > fixed the issue. 
> > 
> > Joseph, is the above right? Anything else to mention? Does the
> > same issue affect also on x86 with vanilla Kernel 4.14.10?
> > 
> > -
> > 
> > It seems that the original patch were designed to solve some IRQ issues
> > with network cards with causes data losses on high traffic. However,
> > it is also causing bad effects on sustained high bandwidth demands
> > required by DVB cards, at least on some USB host drivers.
> > 
> > Alan/Greg/Eric/David:
> > 
> > Any ideas about how to fix it without causing regressions to
> > network?  
> 
> It would be good to know what hardware was involved on the x86 system
> and to have some timing data.  Can we see the output from lsusb and
> usbmon, running on a vanilla kernel that gets plenty of video glitches?

>From Josef's report, and from the BZ, the affected hardware seems
to be based on Montage Technology M88DS3103/M88TS2022 chipset.
The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c,
with shares a USB implementation that is used by a lot more drivers.
The URB handling code is at:

drivers/media/usb/dvb-usb-v2/usb_urb.c

This particular driver allocates 8 buffers with 4096 bytes each
for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP.

This become a popular USB hardware nowadays. I have one S960c
myself, so I can send you the lsusb from it. You should notice, however,
that a DVB-C/DVB-S2 channel can easily provide very high sustained bit
rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps
of payload after removing URB headers. A 10 minutes record with the
entire data (with typically contains 5-10 channels) can easily go
above 4 GB, just to reproduce 1-2 glitches. So, I'm not sure if
a usbmon dump would be useful.

I'm enclosing the lsusb from a S960C device, with is based on those
Montage chipsets:

Bus 002 Device 007: ID 0572:960c Conexant Systems (Rockwell), Inc. DVBSky S960C 
DVB-S2 tuner
Couldn't open device, some information will be missing
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0572 Conexant Systems (Rockwell), Inc.
  idProduct  0x960c DVBSky S960C DVB-S2 tuner
  bcdDevice0.00
  iManufacturer   1 
  iProduct2 
  iSerial 3 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  219
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  4 
bmAttributes 0x80
  (Bus Powered)
MaxPower  

Re: BUG: unable to handle kernel paging request in ipcget

[Dmitry Vyukov]

On Tue, Jan 2, 2018 at 7:16 PM, Kees Cook  wrote:
> On Sat, Dec 23, 2017 at 2:07 AM, Dmitry Vyukov  wrote:
>> On Sat, Dec 23, 2017 at 10:59 AM, Manfred Spraul
>>  wrote:
>>> Hi,
>>>
>>> On 12/23/2017 08:33 AM, syzbot wrote:

 Hello,

 syzkaller hit the following crash on
 6084b576dca2e898f5c101baef151f7bfdbb606d
 git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
 compiler: gcc (GCC) 7.1.1 20170620
 .config is attached
 Raw console output is attached.

 Unfortunately, I don't have any reproducer for this bug yet.

>>> Is one of the recent issues reproducible?
>>
>> Which one do you mean?
>> syzbot always provides up-to-date status of reproducers for all reported 
>> bugs.
>>
>>> Either something is wrong with the faster ipc_get, or the improved ipc_get
>>> makes issues in other areas visible.
>
> Was this report related to the recent set of kmalloc-1024 false positives?


That's possible. It happened only twice and is unexplainable (right?). Let's do:

#syz fix: crypto: pcrypt - fix freeing pcrypt instances

and see if this happens again after the commit lands.

Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE (was: Re: mmotm 2018-01-04-16-19 uploaded)

[Michael Ellerman]

Michal Hocko  writes:

> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
> [...]
>> > Could you give us more information about the failure please. Debugging
>> > patch from http://lkml.kernel.org/r/20171218091302.gl16...@dhcp22.suse.cz
>> > should help to see what is the clashing VMA.
>> 
>> Seems like its re-requesting the same mapping again.
>
> It always seems to be the same mapping which is a bit strange as we
> have multiple binaries here. Are these binaries any special? Does this
> happen to all bianries (except for init which has obviously started
> successfully)? Could you add an additional debugging (at the do_mmap
> layer) to see who is requesting the mapping for the first time?
>
>> [   23.423642] 9148 (sed): Uhuuh, elf segment at 1003 requested 
>> but the memory is mapped already
>> [   23.423706] requested [1003, 1004] mapped [1003, 1004] 
>> 100073 anon
>
> I also find it a bit unexpected that this is an anonymous mapping
> because the elf loader should always map a file backed one.

Anshuman what machine is this on, and what distro and toolchain is it running?

I don't see this on any of my machines, so I wonder if this is
toolchain/distro specific.

cheers

Re: INFO: rcu detected stall in memcpy

[Dmitry Vyukov]

On Thu, Jan 4, 2018 at 6:03 PM, Takashi Iwai  wrote:
> On Thu, 04 Jan 2018 15:17:23 +0100,
> Takashi Iwai wrote:
>>
>> On Thu, 04 Jan 2018 15:01:06 +0100,
>> Dmitry Vyukov wrote:
>> >
>> > On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
>> > > On Thu, 04 Jan 2018 13:08:45 +0100,
>> > > Dmitry Vyukov wrote:
>> > >>
>> > >> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
>> > >>  wrote:
>> > >> > Hello,
>> > >> >
>> > >> > syzkaller hit the following crash on
>> > >> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
>> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> > >> > compiler: gcc (GCC) 7.1.1 20170620
>> > >> > .config is attached
>> > >> > Raw console output is attached.
>> > >> > Unfortunately, I don't have any reproducer for this bug yet.
>> > >> >
>> > >> >
>> > >> > IMPORTANT: if you fix the bug, please add the following tag to the 
>> > >> > commit:
>> > >> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
>> > >> > It will help syzbot understand when the bug is fixed. See footer for
>> > >> > details.
>> > >> > If you forward the report, please keep this part and the footer.
>> > >>
>> > >> This looks ALSA-related. +ALSA maintainers.
>> > >
>> > > Not sure exactly what triggers it.  It's the simple memcpy(), and I
>> > > don't know where RCU is involved in that code path.
>> > >
>> > > BTW, other two suspicious RCU usage reports are actually stopped at
>> > > the second WARN_ON() after the RCU message, and the second WARN_ON()
>> > > is independent from RCU; it's the known spurious WARN_ON() and was
>> > > already removed in the sound git tree.
>> >
>> >
>> > Hi Takashi,
>> >
>> > Another similar one just popped up:
>> >
>> > https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0
>> >
>> > This looks like mulaw_decode enters an infinite loop, or at least
>> > doing very large amount of computations without a resched, e.g.
>> > (uint64_t)-1 number of iterations of something along these lines.
>>
>> OK, that makes sense.
>>
>> My rough guess is that it's the misconfigured aloop device by
>> concurrent setup.  The aloop device allows to restrict the parameters
>> of the other side of the connection, and something bad may happen
>> there if both sides are updated concurrently.
>>
>> We've seen segfault by memset() at loopback_preapre() in
>> sound/drivers/aloop.c by syzbot+3902b5220e8ca27889ca, too, which
>> indicates also the wrongly setup parameters that overflows the
>> allocated buffer.
>
> Below two patches may possibly plug the holes, but I'm not entirely
> sure whether that's the exact culprit.  Could you put them into syzbot
> to watch whether they have any influence?

Hi Takashi,

I've gave an answer to this here:
https://groups.google.com/d/msg/syzkaller-bugs/7ucgCkAJKSk/skZjgavRAQAJ

> In anyway, they are obvious bugs to be fixed, so I'm going to queue to
> my tree.

The options are:
1. You can ask syzbot to test the patch separately. This requires a
reproducer, but there is this bug which has a reproducer and seems to
have the same root cause:
https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ
2. You can reproduce it with the reproducer from here:
https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ
and then test the patch as extensively as needed.
3. If you have some confidence that the patch fixes the problem, then
mark the commit with the tag:
Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
then syzbot will notify if this still happens after the commit reaches
tested trees.

Re: INFO: rcu detected stall in mulaw_decode

[Dmitry Vyukov]

On Thu, Jan 4, 2018 at 2:57 PM, syzbot
 wrote:
> Hello,
>
> syzkaller hit the following crash on
> ad036b63ee57df9ab802a4eb20cbbbec66aa4520
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> Unfortunately, I don't have any reproducer for this bug yet.
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+ebf0a29fce8f37153...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> INFO: rcu_sched self-detected stall on CPU
> 1-: (124999 ticks this GP) idle=71e/1/4611686018427387906
> softirq=9229/9229 fqs=31218
>  (t=125000 jiffies g=4571 c=4570 q=876)
> NMI backtrace for cpu 1
> CPU: 1 PID: 4500 Comm: syz-executor6 Not tainted 4.15.0-rc6-mm1+ #50
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x137/0x198 lib/dump_stack.c:53
>  nmi_cpu_backtrace+0x1d2/0x210 lib/nmi_backtrace.c:103
>  nmi_trigger_cpumask_backtrace+0x122/0x180 lib/nmi_backtrace.c:62
>  arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
>  trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
>  rcu_dump_cpu_stacks+0x186/0x1d7 kernel/rcu/tree.c:1375
>  print_cpu_stall kernel/rcu/tree.c:1524 [inline]
>  check_cpu_stall kernel/rcu/tree.c:1592 [inline]
>  __rcu_pending kernel/rcu/tree.c:3362 [inline]
>  rcu_pending kernel/rcu/tree.c:3424 [inline]
>  rcu_check_callbacks+0x1a64/0x1de0 kernel/rcu/tree.c:2764
>  update_process_times+0x30/0x60 kernel/time/timer.c:1628
>  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
>  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1176
>  __run_hrtimer kernel/time/hrtimer.c:1210 [inline]
>  __hrtimer_run_queues+0x2c8/0xb50 kernel/time/hrtimer.c:1274
>  hrtimer_interrupt+0x1c2/0x5e0 kernel/time/hrtimer.c:1308
>  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>  smp_apic_timer_interrupt+0xc9/0x4c0 arch/x86/kernel/apic/apic.c:1050
>  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
>  
> RIP: 0010:__memcpy+0x0/0x20
> RSP: 0018:8801cd597918 EFLAGS: 0246 ORIG_RAX: ff11
> RAX: f5200028 RBX: 0002 RCX: 83b7d25e
> RDX: 0002 RSI: 8801cd597a00 RDI: c900012aaab8
> RBP: 8801cd597938 R08: f5200028 R09: f5200028
> R10: 0001 R11: f5200027 R12: c900012aaab8
> R13: 8801cd597a00 R14: 8801d0e45000 R15: dc00
>  memcpy include/linux/string.h:344 [inline]
>  cvt_s16_to_native sound/core/oss/mulaw.c:164 [inline]
>  mulaw_decode+0x50e/0x740 sound/core/oss/mulaw.c:195
>  mulaw_transfer+0x222/0x270 sound/core/oss/mulaw.c:273
>  snd_pcm_plug_write_transfer+0x20b/0x390 sound/core/oss/pcm_plugin.c:611
>  snd_pcm_oss_write2+0x22e/0x3c0 sound/core/oss/pcm_oss.c:1311
>  snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1372 [inline]
>  snd_pcm_oss_write+0x4c1/0x690 sound/core/oss/pcm_oss.c:2646
>  __vfs_write+0xef/0x740 fs/read_write.c:480
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xd4/0x1a0 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x452ac9
> RSP: 002b:7febc940bc58 EFLAGS: 0212 ORIG_RAX: 0001
> RAX: ffda RBX: 0071bf58 RCX: 00452ac9
> RDX: ffa2 RSI: 20001000 RDI: 0013
> RBP: 0521 R08:  R09: 
> R10:  R11: 0212 R12: 006f5bb8
> R13:  R14: 7febc940c6d4 R15: 000b


+ALSA maintainers

This looks like:

#syz dup: INFO: rcu detected stall in memcpy

right?



> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d

[PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all

[Vincent Legoll]

No need to get into the submenu to disable all VIRTIO-related
config entries.

This makes it easier to disable all VIRTIO config options
without entering the submenu. It will also enable one
to see that en/dis-abled state from the outside menu.

This is only intended to change menuconfig UI, not change
the config dependencies.

v2: Added "default y" to avoid breaking existing configs
v3: Fixed wrong indentation, added *-by from Randy

Signed-off-by: Vincent Legoll 
Reviewed-by: Randy Dunlap 
Tested-by: Randy Dunlap  # works for me
---
 drivers/virtio/Kconfig | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index cff773f15b7e..35897649c24f 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -5,7 +5,11 @@ config VIRTIO
  bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_RPMSG
  or CONFIG_S390_GUEST.
 
-menu "Virtio drivers"
+menuconfig VIRTIO_MENU
+   bool "Virtio drivers"
+   default y
+
+if VIRTIO_MENU
 
 config VIRTIO_PCI
tristate "PCI driver for virtio devices"
@@ -79,4 +83,4 @@ config VIRTIO_MMIO_CMDLINE_DEVICES
 
 If unsure, say 'N'.
 
-endmenu
+endif # VIRTIO_MENU
-- 
2.14.1

Re: [PATCH v2] x86/mm/pti: remove dead logic during user pagetable population

[Borislav Petkov]

On Sun, Jan 07, 2018 at 06:33:17PM +0800, Jike Song wrote:
> Look at one of the code snippets:
> 
> 162 if (pgd_none(*pgd)) {
> 163 unsigned long new_p4d_page = __get_free_page(gfp);
> 164 if (!new_p4d_page)
> 165 return NULL;
> 166
> 167 if (pgd_none(*pgd)) {
> 168 set_pgd(pgd, __pgd(_KERNPG_TABLE | 
> __pa(new_p4d_page)));
> 169 new_p4d_page = 0;
> 170 }
> 171 if (new_p4d_page)
> 172 free_page(new_p4d_page);
> 173 }
> 
> There can't be any difference between two pgd_none(*pgd) at L162 and L167,
> so it's always false at L171.

I think this is a remnant from the kaiser version which did this:

if (pud_none(*pud)) {
unsigned long new_pmd_page = __get_free_page(gfp);
if (!new_pmd_page)
return NULL;
spin_lock(&shadow_table_allocation_lock);
if (pud_none(*pud))
set_pud(pud, __pud(_KERNPG_TABLE | __pa(new_pmd_page)));
else
free_page(new_pmd_page);
spin_unlock(&shadow_table_allocation_lock);
}

I was wondering too, why the duplicated checks.

Which has this explanation about the need for the locking:

/*
 * At runtime, the only things we map are some things for CPU
 * hotplug, and stacks for new processes.  No two CPUs will ever
 * be populating the same addresses, so we only need to ensure
 * that we protect between two CPUs trying to allocate and
 * populate the same page table page.
 *
 * Only take this lock when doing a set_p[4um]d(), but it is not
 * needed for doing a set_pte().  We assume that only the *owner*
 * of a given allocation will be doing this for _their_
 * allocation.
 *
 * This ensures that once a system has been running for a while
 * and there have been stacks all over and these page tables
 * are fully populated, there will be no further acquisitions of
 * this lock.
 */
static DEFINE_SPINLOCK(shadow_table_allocation_lock);

Now I have my suspicions why that's not needed anymore upstream but I'd
let tglx explain better.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[GIT PULL 4/4] ARM: exynos/samsung: Stuff for v4.16

[Krzysztof Kozlowski]

The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:

  Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-soc-4.16-2

for you to fetch changes up to 4490e3c688d9e409a98189a6ea08bc2823d452e2:

  ARM: SAMSUNG: Add SPDX license identifiers (2018-01-03 18:43:13 +0100)


Samsung mach/soc changes for v4.16

Add SPDX license identifiers.


Krzysztof Kozlowski (5):
  ARM: EXYNOS: Add SPDX license identifiers
  ARM: S3C24XX: Add SPDX license identifiers
  ARM: S3C64XX: Add SPDX license identifiers
  ARM: S5PV210: Add SPDX license identifiers
  ARM: SAMSUNG: Add SPDX license identifiers

 arch/arm/mach-exynos/Kconfig   |  4 +--
 arch/arm/mach-exynos/Makefile  |  4 +--
 arch/arm/mach-exynos/common.h  |  5 +--
 arch/arm/mach-exynos/exynos-smc.S  |  5 +--
 arch/arm/mach-exynos/exynos.c  | 16 -
 arch/arm/mach-exynos/firmware.c| 14 +++-
 arch/arm/mach-exynos/headsmp.S |  6 +---
 arch/arm/mach-exynos/include/mach/map.h|  7 ++--
 arch/arm/mach-exynos/mcpm-exynos.c | 17 +++---
 arch/arm/mach-exynos/platsmp.c | 21 +---
 arch/arm/mach-exynos/pm.c  | 24 ++---
 arch/arm/mach-exynos/sleep.S   | 11 +-
 arch/arm/mach-exynos/smc.h |  5 +--
 arch/arm/mach-exynos/suspend.c | 24 ++---
 arch/arm/mach-s3c24xx/Kconfig  |  4 +--
 arch/arm/mach-s3c24xx/Makefile |  4 +--
 arch/arm/mach-s3c24xx/Makefile.boot|  2 ++
 arch/arm/mach-s3c24xx/anubis.h |  7 ++--
 arch/arm/mach-s3c24xx/bast-ide.c   | 17 --
 arch/arm/mach-s3c24xx/bast-irq.c   | 28 
 arch/arm/mach-s3c24xx/bast.h   |  7 ++--
 arch/arm/mach-s3c24xx/common-smdk.c| 21 +---
 arch/arm/mach-s3c24xx/common-smdk.h|  7 ++--
 arch/arm/mach-s3c24xx/common.c | 29 
 arch/arm/mach-s3c24xx/common.h |  5 +--
 arch/arm/mach-s3c24xx/cpufreq-utils.c  | 18 --
 arch/arm/mach-s3c24xx/fb-core.h|  5 +--
 arch/arm/mach-s3c24xx/gta02.h  |  7 ++--
 arch/arm/mach-s3c24xx/h1940-bluetooth.c| 16 +++--
 arch/arm/mach-s3c24xx/h1940.h  |  7 ++--
 arch/arm/mach-s3c24xx/include/mach/dma.h   | 10 ++
 arch/arm/mach-s3c24xx/include/mach/fb.h|  1 +
 arch/arm/mach-s3c24xx/include/mach/gpio-samsung.h  |  7 ++--
 arch/arm/mach-s3c24xx/include/mach/hardware.h  |  7 ++--
 arch/arm/mach-s3c24xx/include/mach/irqs.h  | 10 ++
 arch/arm/mach-s3c24xx/include/mach/map.h   | 10 ++
 arch/arm/mach-s3c24xx/include/mach/pm-core.h   |  9 ++---
 arch/arm/mach-s3c24xx/include/mach/regs-clock.h| 10 ++
 arch/arm/mach-s3c24xx/include/mach/regs-gpio.h | 10 ++
 arch/arm/mach-s3c24xx/include/mach/regs-irq.h  | 10 ++
 arch/arm/mach-s3c24xx/include/mach/regs-lcd.h  | 11 ++
 .../mach-s3c24xx/include/mach/regs-s3c2443-clock.h | 10 ++
 arch/arm/mach-s3c24xx/include/mach/rtc-core.h  |  7 ++--
 arch/arm/mach-s3c24xx/include/mach/s3c2412.h   |  5 +--
 arch/arm/mach-s3c24xx/iotiming-s3c2410.c   | 18 --
 arch/arm/mach-s3c24xx/iotiming-s3c2412.c   | 18 --
 arch/arm/mach-s3c24xx/irq-pm.c | 19 ---
 arch/arm/mach-s3c24xx/mach-amlm5900.c  | 35 +--
 arch/arm/mach-s3c24xx/mach-anubis.c| 15 +++--
 arch/arm/mach-s3c24xx/mach-at2440evb.c | 21 +---
 arch/arm/mach-s3c24xx/mach-bast.c  | 17 --
 arch/arm/mach-s3c24xx/mach-gta02.c | 33 +-
 arch/arm/mach-s3c24xx/mach-h1940.c | 17 --
 arch/arm/mach-s3c24xx/mach-jive.c  | 17 --
 arch/arm/mach-s3c24xx/mach-mini2440.c  | 23 +
 arch/arm/mach-s3c24xx/mach-n30.c   | 27 +++
 arch/arm/mach-s3c24xx/mach-nexcoder.c  | 22 +---
 arch/arm/mach-s3c24xx/mach-osiris-dvs.c| 19 ---
 arch/arm/mach-s3c24xx/mach-osiris.c| 14 +++-
 arch/arm/mach-s3c24xx/mach-otom.c  | 13 +++-
 arch/arm/mach-s3c24xx/mach-qt2410.c| 27 +++
 arch/arm/mach-s3c24xx/mach-rx1950.c| 17 --
 arch/arm/mach-s3c24xx/mach-rx3715.c  

[GIT PULL 1/4] ARM: dts: exynos: Stuff for v4.16, 2nd round

[Krzysztof Kozlowski]

Hi,

On top of previous pull request.

Best regards,
Krzysztof


The following changes since commit 3be1ecf291df8191f5ea395d363acc8fa029b5fd:

  ARM: dts: exynos: Use lower case hex addresses in node unit addresses 
(2017-12-18 18:15:51 +0100)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-dt-4.16-2

for you to fetch changes up to 5628a8ca14149ba4226e3bdce3a04c3b688435ad:

  ARM: dts: exynos: fix RTC interrupt for exynos5410 (2018-01-07 11:15:59 +0100)


Samsung DTS ARM changes for 4.16, part 2

1. Add SPDX license identifiers.
2. Properly fix DTC warning for PMU/RTC interrupts on Exynos5410.


Arnd Bergmann (1):
  ARM: dts: exynos: fix RTC interrupt for exynos5410

Krzysztof Kozlowski (5):
  ARM: dts: exynos: Add SPDX license identifiers
  ARM: dts: s3c24xx: Add SPDX license identifiers
  ARM: dts: s3c64xx: Add SPDX license identifiers
  ARM: dts: s5pv210: Add SPDX license identifiers
  Revert "ARM: dts: exynos: Add missing interrupt-controller properties to 
Exynos5410 PMU"

 arch/arm/boot/dts/exynos3250-artik5-eval.dts   | 5 +
 arch/arm/boot/dts/exynos3250-artik5.dtsi   | 5 +
 arch/arm/boot/dts/exynos3250-monk.dts  | 5 +
 arch/arm/boot/dts/exynos3250-pinctrl.dtsi  | 7 ++-
 arch/arm/boot/dts/exynos3250-rinato.dts| 5 +
 arch/arm/boot/dts/exynos3250.dtsi  | 5 +
 arch/arm/boot/dts/exynos4-cpu-thermal.dtsi | 6 +-
 arch/arm/boot/dts/exynos4.dtsi | 5 +
 arch/arm/boot/dts/exynos4210-origen.dts| 7 ++-
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi  | 7 ++-
 arch/arm/boot/dts/exynos4210-smdkv310.dts  | 7 ++-
 arch/arm/boot/dts/exynos4210-trats.dts | 7 ++-
 arch/arm/boot/dts/exynos4210-universal_c210.dts| 7 ++-
 arch/arm/boot/dts/exynos4210.dtsi  | 7 ++-
 arch/arm/boot/dts/exynos4412-itop-elite.dts| 5 +
 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi| 5 +
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 5 +
 arch/arm/boot/dts/exynos4412-odroidu3.dts  | 7 ++-
 arch/arm/boot/dts/exynos4412-odroidx.dts   | 7 ++-
 arch/arm/boot/dts/exynos4412-odroidx2.dts  | 7 ++-
 arch/arm/boot/dts/exynos4412-origen.dts| 7 ++-
 arch/arm/boot/dts/exynos4412-pinctrl.dtsi  | 7 ++-
 arch/arm/boot/dts/exynos4412-ppmu-common.dtsi  | 5 +
 arch/arm/boot/dts/exynos4412-prime.dtsi| 5 +
 arch/arm/boot/dts/exynos4412-smdk4412.dts  | 7 ++-
 arch/arm/boot/dts/exynos4412.dtsi  | 7 ++-
 arch/arm/boot/dts/exynos5.dtsi | 5 +
 arch/arm/boot/dts/exynos5250-arndale.dts   | 5 +
 arch/arm/boot/dts/exynos5250-pinctrl.dtsi  | 7 ++-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  | 5 +
 arch/arm/boot/dts/exynos5250-snow-common.dtsi  | 5 +
 arch/arm/boot/dts/exynos5250-snow-rev5.dts | 5 +
 arch/arm/boot/dts/exynos5250-snow.dts  | 5 +
 arch/arm/boot/dts/exynos5250-spring.dts| 5 +
 arch/arm/boot/dts/exynos5250.dtsi  | 7 ++-
 arch/arm/boot/dts/exynos5260-pinctrl.dtsi  | 7 ++-
 arch/arm/boot/dts/exynos5260-xyref5260.dts | 7 ++-
 arch/arm/boot/dts/exynos5260.dtsi  | 7 ++-
 arch/arm/boot/dts/exynos5410-odroidxu.dts  | 5 +
 arch/arm/boot/dts/exynos5410-pinctrl.dtsi  | 5 +
 arch/arm/boot/dts/exynos5410-smdk5410.dts  | 7 ++-
 arch/arm/boot/dts/exynos5410.dtsi  | 9 +
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  | 7 ++-
 arch/arm/boot/dts/exynos5420-cpus.dtsi | 5 +
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 +
 arch/arm/boot/dts/exynos5420-pinctrl.dtsi  | 7 ++-
 arch/arm/boot/dts/exynos5420-smdk5420.dts  | 7 ++-
 arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi  | 6 +-
 arch/arm/boot/dts/exynos5420-trip-points.dtsi  | 6 +-
 arch/arm/boot/dts/exynos5420.dtsi  | 5 +
 arch/arm/boot/dts/exynos5422-cpus.dtsi | 5 +
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi  | 7 ++-
 arch/arm/boot/dts/exynos5422-odroidhc1.dts | 7 ++-
 arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi  | 7 ++-
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
 arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts| 7 ++-
 arch/arm/boot/dts/exynos5422-odroidxu3.dts | 7 ++-
 arch/arm/boot/dts/exynos5422-odroidxu4.dts | 7 ++-
 arch/arm/boot/dts/exynos5440-sd5v1.dts | 7 ++-
 arch/arm/boot/dts/exynos5440-ssdk5440.dts  | 

[GIT PULL 2/4] arm64: dts: exynos: Stuff for v4.16, 2nd round

[Krzysztof Kozlowski]

Hi,

On top of previous pull request.

Best regards,
Krzysztof


The following changes since commit 3808354701090723b53c73afaccfcafdeb8a5bfe:

  arm64: dts: exynos: Increase bus frequency for MHL chip (2017-12-04 17:51:10 
+0100)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-dt64-4.16-2

for you to fetch changes up to 45fef752126603d591754befa63d0a800492eb6c:

  arm64: dts: exynos: Add SPDX license identifiers (2018-01-03 18:16:35 +0100)


Samsung DTS ARM64 changes for v4.16, part 2

1. Fix DTC warnings around unit addresses.
2. Add SPDX license identifiers.


Krzysztof Kozlowski (3):
  arm64: dts: exynos: Use lower case hex addresses in node unit addresses
  arm64: dts: exynos: Fix typo in MSCL clock controller unit address of 
Exynos5433
  arm64: dts: exynos: Add SPDX license identifiers

 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi|  5 +
 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi|  5 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi |  5 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts |  5 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts|  5 +
 .../boot/dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi   |  5 +
 .../arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi |  5 +
 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi|  5 +
 arch/arm64/boot/dts/exynos/exynos5433.dtsi| 15 ++-
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts   |  7 ++-
 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi   |  7 ++-
 arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi   |  6 +-
 arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi   |  6 +-
 arch/arm64/boot/dts/exynos/exynos7.dtsi   |  9 +++--
 14 files changed, 23 insertions(+), 67 deletions(-)

[GIT PULL 3/4] soc: samsung: Stuff for v4.16

[Krzysztof Kozlowski]

The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:

  Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-drivers-4.16-2

for you to fetch changes up to 06512c539ff1d6d008d5e8ab9d6f5f6405972f53:

  soc: samsung: Add SPDX license identifiers (2018-01-03 18:45:15 +0100)


Samsung soc drivers changes for v4.16

Add SPDX license identifiers.


Krzysztof Kozlowski (1):
  soc: samsung: Add SPDX license identifiers

 drivers/soc/samsung/Kconfig  |  1 +
 drivers/soc/samsung/Makefile |  1 +
 drivers/soc/samsung/exynos-pmu.c | 16 ++--
 drivers/soc/samsung/exynos-pmu.h |  5 +
 drivers/soc/samsung/exynos3250-pmu.c | 16 ++--
 drivers/soc/samsung/exynos4-pmu.c| 16 ++--
 drivers/soc/samsung/exynos5250-pmu.c | 16 ++--
 drivers/soc/samsung/exynos5420-pmu.c | 16 ++--
 drivers/soc/samsung/pm_domains.c | 24 ++--
 9 files changed, 43 insertions(+), 68 deletions(-)

[GIT PULL 0/4] ARM: exynos: Second pull for v4.16

[Krzysztof Kozlowski]

Hi,

Last round of updates for v4.16. Two tags based on previous.

Best regards,
Krzysztof

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

[Borislav Petkov]

On Sun, Jan 07, 2018 at 09:40:42AM +, David Woodhouse wrote:
> Right, so it all tends to work out OK purely by virtue of the fact that
> oldinstr and altinstr end up far enough apart in the image that they're
> 5-byte jumps. Which isn't perfect but we've lived with worse.

Well, the reference point is important. And I don't think we've done
more involved things than jumping back to something in .text proper.
However, I think I know how to fix this so that arbitrary jump offsets
would work but I need to talk to our gcc guys first.

If the jump is close enough for 2 bytes, then it should work as long as
the offset to the target doesn't change.

The main thing recompute_jumps() does is turn 5-byte jumps - which gas
creates because the jump target is in .text but the jump itself is in
.altinstr_replacement - into 2-byte ones. Because when you copy the jump
back into .text, the offset might fit in a signed byte all of a sudden.

There are still some nasties with forcing 5-byte jumps but I think I
know how to fix those. Stay tuned...

> I'm relatively pleased that we've managed to eliminate this as a
> dependency for inverting the X86_FEATURE_RETPOLINE logic though, by
> following Linus' suggestion to just emit the thunk inline instead of
> calling the same one as GCC.
> 
> The other fun one for alternatives is in entry_64.S, where we really
> need the return address of the call instruction to be *precisely* the 
> .Lentry_SYSCALL_64_after_fastpath_call label, so we have to eschew the
> normal NOSPEC_CALL there:

So CALL, as the doc says, pushes the offset of the *next* insn onto the
stack and branches to the target address.

So I'm thinking, as long as the next insn doesn't move and gcc doesn't
pad anything, you're fine.

However, I suspect that I'm missing something else here and I guess I'll
have more clue if I look at the whole thing. So can you point me to your
current branch so that I can take a look at the code?

Thx.

-- 
Regards/Gruss,
Boris.

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

[PATCH v2 0/2] video/fbdev/stifb: Adjustments for stifb_init_fb()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 7 Jan 2018 12:45:54 +0100

Two update suggestions were taken into account.

Markus Elfring (2):
  Return -ENOMEM after a failed kzalloc()
  Delete an error message for a failed memory allocation

 drivers/video/fbdev/stifb.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

-- 
2.15.1

[PATCH v2 1/2] video/fbdev/stifb: Return -ENOMEM after a failed kzalloc() in stifb_init_fb()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 7 Jan 2018 11:33:59 +0100

Replace an error code for the indication of a memory allocation failure
in this function.

Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac ("Linux-2.6.12-rc2: Initial git 
repository build")
Suggested-by: Rolf Eike Beer 
Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/stifb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index 6ded5c198998..511a594889af 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -1128,7 +1128,7 @@ static int __init stifb_init_fb(struct sti_struct *sti, 
int bpp_pref)
fb = kzalloc(sizeof(*fb), GFP_ATOMIC);
if (!fb) {
printk(KERN_ERR "stifb: Could not allocate stifb structure\n");
-   return -ENODEV;
+   return -ENOMEM;
}

info = &fb->info;
-- 
2.15.1

[PATCH v2 2/2] video/fbdev/stifb: Delete an error message for a failed memory allocation in stifb_init_fb()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 7 Jan 2018 12:34:22 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
This update suggestion was rebased on source files from the software
"Linux next-20180105" together with a change for an error code.

 drivers/video/fbdev/stifb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index 511a594889af..dec8efb4f256 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -1126,10 +1126,8 @@ static int __init stifb_init_fb(struct sti_struct *sti, 
int bpp_pref)
int bpp, xres, yres;
 
fb = kzalloc(sizeof(*fb), GFP_ATOMIC);
-   if (!fb) {
-   printk(KERN_ERR "stifb: Could not allocate stifb structure\n");
+   if (!fb)
return -ENOMEM;
-   }

info = &fb->info;
 
-- 
2.15.1

Re: [PATCH v2 1/6] ARM: at91: add TCB registers definitions

[Philippe Ombredanne]

On Fri, Jan 5, 2018 at 3:30 PM, Alexandre Belloni
 wrote:
> Add registers and bits definitions for the timer counter blocks found on
> Atmel ARM SoCs.
>
> Signed-off-by: Alexandre Belloni 
> ---
>  include/soc/at91/atmel_tcb.h | 229 
> +++
>  1 file changed, 229 insertions(+)
>  create mode 100644 include/soc/at91/atmel_tcb.h
>
> diff --git a/include/soc/at91/atmel_tcb.h b/include/soc/at91/atmel_tcb.h
> new file mode 100644
> index ..f48e60f8ab92
> --- /dev/null
> +++ b/include/soc/at91/atmel_tcb.h
> @@ -0,0 +1,229 @@
> +/*
> + * Copyright (C) 2016 Atmel
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */

Alexandre,
Would you mind using SPDx tags here like you did in
/drivers/clocksource/timer-atmel-tcb.c ?
Thanks!
-- 
Cordially
Philippe Ombredanne

Re: [PATCH v2 2/8] x86/enter: MACROS to set/clear IBRS

[Borislav Petkov]

On Fri, Jan 05, 2018 at 06:12:17PM -0800, Tim Chen wrote:

> Subject: Re: [PATCH v2 2/8] x86/enter: MACROS to set/clear IBRS

Your subject needs to have a verb and not scream:

Subject: [PATCH v2 2/8] x86/entry: Add macros to set/clear IBRS

> Create macros to control IBRS.  Use these macros to enable IBRS on kernel 
> entry
> paths and disable IBRS on kernel exit paths.
> 
> The registers rax, rcx and rdx are touched when controlling IBRS
> so they need to be saved when they can't be clobbered.
> 
> Signed-off-by: Tim Chen 
> ---
>  arch/x86/entry/calling.h | 74 
> 
>  1 file changed, 74 insertions(+)
> 
> diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h
> index 45a63e0..09c870d 100644
> --- a/arch/x86/entry/calling.h
> +++ b/arch/x86/entry/calling.h
> @@ -6,6 +6,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /*
>  
> @@ -347,3 +349,75 @@ For 32-bit we have the following conventions - kernel is 
> built with
>  .Lafter_call_\@:
>  #endif
>  .endm
> +
> +/*
> + * IBRS related macros
> + */
> +.macro PUSH_MSR_REGS
> + pushq   %rax
> + pushq   %rcx
> + pushq   %rdx
> +.endm
> +
> +.macro POP_MSR_REGS
> + popq%rdx
> + popq%rcx
> + popq%rax
> +.endm
> +
> +.macro WRMSR_ASM msr_nr:req eax_val:req

WRMSR as a name is good enough.

Also, you need edx_val:req too in case we decide to reuse that macro
for something else later. Which I'm pretty sure we will, once it is out
there.

> + movl\msr_nr, %ecx
> + movl$0, %edx

... and then

movl\edx_val, %edx

> + movl\eax_val, %eax
> +.endm
> +
> +.macro ENABLE_IBRS
> + ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
> + PUSH_MSR_REGS
> + WRMSR_ASM $MSR_IA32_SPEC_CTRL, $SPEC_CTRL_FEATURE_ENABLE_IBRS

This is overwriting the previous contents of the MSR. You need to read
it and OR-in its bits [63:2] with SPEC_CTRL_FEATURE_ENABLE_IBRS and
clear bit 0.

Unless the rest of this MSR is not going to be used for anything else.
Then you're fine.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

[Philippe Ombredanne]

Knut,

On Fri, Jan 5, 2018 at 3:30 PM, Jani Nikula  wrote:
> On Thu, 04 Jan 2018, Knut Omang  wrote:
>> On Thu, 2018-01-04 at 17:50 +0200, Jani Nikula wrote:
>>> On Thu, 04 Jan 2018, Knut Omang  wrote:
>>> > Add scripts/runchecks which has generic support for running
>>> > checker tools in a convenient and user friendly way that
>>> > the author hopes can contribute to rein in issues detected
>>> > by these tools in a manageable and convenient way.



>>> > --- /dev/null
>>> > +++ b/scripts/runchecks
>>> > @@ -0,0 +1,734 @@
>>> > +#!/usr/bin/python
>>> > +
>>> > +# SPDX-License-Identifier: GPL-2.0

Thank you for using an SPDX tag here   .



>>> > +#
>>> > +# 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.
>>> > +

but then please DRY: do not add this extra legalese which is redundant.

-- 
Cordially
Philippe Ombredanne

Re: [PATCH v2] x86/mm/pti: remove dead logic during user pagetable population

[Thomas Gleixner]

On Sun, 7 Jan 2018, Borislav Petkov wrote:
> On Sun, Jan 07, 2018 at 06:33:17PM +0800, Jike Song wrote:
> > Look at one of the code snippets:
> > 
> > 162 if (pgd_none(*pgd)) {
> > 163 unsigned long new_p4d_page = __get_free_page(gfp);
> > 164 if (!new_p4d_page)
> > 165 return NULL;
> > 166
> > 167 if (pgd_none(*pgd)) {
> > 168 set_pgd(pgd, __pgd(_KERNPG_TABLE | 
> > __pa(new_p4d_page)));
> > 169 new_p4d_page = 0;
> > 170 }
> > 171 if (new_p4d_page)
> > 172 free_page(new_p4d_page);
> > 173 }
> > 
> > There can't be any difference between two pgd_none(*pgd) at L162 and L167,
> > so it's always false at L171.
> 
> I think this is a remnant from the kaiser version which did this:
> 
> if (pud_none(*pud)) {
> unsigned long new_pmd_page = __get_free_page(gfp);
> if (!new_pmd_page)
> return NULL;
> spin_lock(&shadow_table_allocation_lock);
> if (pud_none(*pud))
> set_pud(pud, __pud(_KERNPG_TABLE | 
> __pa(new_pmd_page)));
> else
> free_page(new_pmd_page);
> spin_unlock(&shadow_table_allocation_lock);
> }
> 
> I was wondering too, why the duplicated checks.
> 
> Which has this explanation about the need for the locking:
> 
> /*
>  * At runtime, the only things we map are some things for CPU
>  * hotplug, and stacks for new processes.  No two CPUs will ever
>  * be populating the same addresses, so we only need to ensure
>  * that we protect between two CPUs trying to allocate and
>  * populate the same page table page.
>  *
>  * Only take this lock when doing a set_p[4um]d(), but it is not
>  * needed for doing a set_pte().  We assume that only the *owner*
>  * of a given allocation will be doing this for _their_
>  * allocation.
>  *
>  * This ensures that once a system has been running for a while
>  * and there have been stacks all over and these page tables
>  * are fully populated, there will be no further acquisitions of
>  * this lock.
>  */
> static DEFINE_SPINLOCK(shadow_table_allocation_lock);
> 
> Now I have my suspicions why that's not needed anymore upstream but I'd
> let tglx explain better.

We got rid of all that runtime mapping stuff and the functions are only
called from pti_init(). So the locking and therefor the tests above are not
needed anymore. While at it we should mark all those function __init.

Thanks,

tglx

Re: [PATCH] staging: ccree: shorten lengthy lines with breaks

[Gilad Ben-Yossef]

Hi George,

On Sat, Jan 6, 2018 at 5:47 PM, George Edward Bulmer
 wrote:
> This fixes five instances of checkpatch warning:
> WARNING: line over 80 characters
>

Thank you for the patch.


> Signed-off-by: George Edward Bulmer 
> ---
>  drivers/staging/ccree/ssi_sysfs.c | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)

Unfortunately, I believe you are not working with the latest
staging-next tree as
this issue and indeed the file it appears in are not longer there.

Many thanks,
Gilad

[PATCH v3 01/27] staging: ccree: SPDXify driver

[Gilad Ben-Yossef]

Replace verbatim GPL v2 copy with SPDX tag.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig|  2 ++
 drivers/staging/ccree/Makefile   |  2 ++
 drivers/staging/ccree/cc_crypto_ctx.h| 17 ++---
 drivers/staging/ccree/cc_debugfs.c   | 17 ++---
 drivers/staging/ccree/cc_debugfs.h   | 17 ++---
 drivers/staging/ccree/cc_hw_queue_defs.h | 17 ++---
 drivers/staging/ccree/cc_lli_defs.h  | 17 ++---
 drivers/staging/ccree/dx_crys_kernel.h   | 17 ++---
 drivers/staging/ccree/dx_host.h  | 17 ++---
 drivers/staging/ccree/dx_reg_common.h| 17 ++---
 drivers/staging/ccree/hash_defs.h| 17 ++---
 drivers/staging/ccree/ssi_aead.c | 17 ++---
 drivers/staging/ccree/ssi_aead.h | 17 ++---
 drivers/staging/ccree/ssi_buffer_mgr.c   | 17 ++---
 drivers/staging/ccree/ssi_buffer_mgr.h   | 17 ++---
 drivers/staging/ccree/ssi_cipher.c   | 17 ++---
 drivers/staging/ccree/ssi_cipher.h   | 17 ++---
 drivers/staging/ccree/ssi_driver.c   | 17 ++---
 drivers/staging/ccree/ssi_driver.h   | 17 ++---
 drivers/staging/ccree/ssi_fips.c | 17 ++---
 drivers/staging/ccree/ssi_fips.h | 17 ++---
 drivers/staging/ccree/ssi_hash.c | 17 ++---
 drivers/staging/ccree/ssi_hash.h | 17 ++---
 drivers/staging/ccree/ssi_ivgen.c| 17 ++---
 drivers/staging/ccree/ssi_ivgen.h| 17 ++---
 drivers/staging/ccree/ssi_pm.c   | 17 ++---
 drivers/staging/ccree/ssi_pm.h   | 17 ++---
 drivers/staging/ccree/ssi_request_mgr.c  | 17 ++---
 drivers/staging/ccree/ssi_request_mgr.h  | 17 ++---
 drivers/staging/ccree/ssi_sram_mgr.c | 17 ++---
 drivers/staging/ccree/ssi_sram_mgr.h | 17 ++---
 31 files changed, 62 insertions(+), 435 deletions(-)

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index 0b3092b..c94dfe8 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
 config CRYPTO_DEV_CCREE
tristate "Support for ARM TrustZone CryptoCell C7XX family of Crypto 
accelerators"
depends on CRYPTO && CRYPTO_HW && OF && HAS_DMA
diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index ab9f073..bb47144 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
 ccree-y := ssi_driver.o ssi_buffer_mgr.o ssi_request_mgr.o ssi_cipher.o 
ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o
 ccree-$(CONFIG_CRYPTO_FIPS) += ssi_fips.o
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index 0e34d9a..02e14f3 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -1,18 +1,5 @@
-/*
- * Copyright (C) 2012-2017 ARM Limited or its affiliates.
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- */
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
 
 #ifndef _CC_CRYPTO_CTX_H_
 #define _CC_CRYPTO_CTX_H_
diff --git a/drivers/staging/ccree/cc_debugfs.c 
b/drivers/staging/ccree/cc_debugfs.c
index 662fa07..ab2c986 100644
--- a/drivers/staging/ccree/cc_debugfs.c
+++ b/drivers/staging/ccree/cc_debugfs.c
@@ -1,18 +1,5 @@
-/*
- * Copyright (C) 2012-2017 ARM Limited or its affiliates.
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- */
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2012-2018 ARM Limited or its affiliates

[PATCH v3 00/27] staging: ccree: fixes and cleanups

[Gilad Ben-Yossef]

The usual combo of code cleanups and fixes.

The highlights are:
- Use SPDX for all driver copyright/license
- Make ccree compliant with crypto API handling of backlog requests
- Make ccree compliant with Crypto API rules of resource alloc/release
- Settle on a single coherent file naming convention (which is why
  the diff looks so big)

Note that there are some fixes in the set that I currently consider
out of scope for stable. I will consider if I can/should roll
separate minimal fix patches for stable after these are taken.

With this set of changes, I've handled anything that I know about
that keeps it from moving out of staging to the best of my understanding
and would like to ask for a review before moving out of staging.

Signed-off-by: Gilad Ben-Yossef 

Changes from v2:
- Revert to SPDX-2.0 license tags as the kernel tools are not
  ready yet for 3.0

Changes from v1:
- Fixed wrong use of CPP style comments in SPDX include file
  headers as pointed out by Philippe Ombredanne.
- Moved to using SPDX-3.0 style GPL-2.0-only tags
- Rephrased one commit message to better clarify it is a fix
  and not just a cleanup
- Separated two commits which got squashed together unintentionally 
- Rebased on top of latest staging-next

Gilad Ben-Yossef (27):
  staging: ccree: SPDXify driver
  staging: ccree: fold hash defs into queue defs
  staging: ccree: fold reg common defines into driver
  staging: ccree: remove GFP_DMA flag from mem allocs
  staging: ccree: pick alloc mem flags based on req flags
  staging: ccree: copy larval digest from RAM
  staging: ccree: tag debugfs init/exit func properly
  staging: ccree: remove unused leftover field
  staging: ccree: break send_request and fix ret val
  staging: ccree: add backlog processing
  stating: ccree: revert "staging: ccree: fix leak of import() after
init()"
  staging: ccree: failing the suspend is not an error
  staging: ccree: check DMA pool buf !NULL  before free
  staging: ccree: handle end of sg list gracefully
  staging: ccree: use Makefile to include PM code
  staging: ccree: remove unused field
  staging: ccree: use array for double buffer
  staging: ccree: allocate hash bufs inside req ctx
  staging: ccree: do not map bufs in ahash_init
  staging: ccree: fix indentation of func params
  staging: ccree: fold common code into service func
  staging: ccree: put pointer next to var name
  stating: ccree: fix allocation of void sized buf
  staging: ccree: use a consistent file naming convention
  staging: ccree: remove unneeded includes
  staging: ccree: update TODO
  staging: ccree: add missing include

 drivers/staging/ccree/Kconfig|2 +
 drivers/staging/ccree/Makefile   |7 +-
 drivers/staging/ccree/TODO   |2 +-
 drivers/staging/ccree/cc_aead.c  | 2702 +
 drivers/staging/ccree/cc_aead.h  |  109 ++
 drivers/staging/ccree/cc_buffer_mgr.c| 1651 ++
 drivers/staging/ccree/cc_buffer_mgr.h|   74 +
 drivers/staging/ccree/cc_cipher.c| 1167 +
 drivers/staging/ccree/cc_cipher.h|   74 +
 drivers/staging/ccree/cc_crypto_ctx.h|   21 +-
 drivers/staging/ccree/cc_debugfs.c   |   24 +-
 drivers/staging/ccree/cc_debugfs.h   |   17 +-
 drivers/staging/ccree/cc_driver.c|  477 ++
 drivers/staging/ccree/cc_driver.h|  194 +++
 drivers/staging/ccree/cc_fips.c  |  112 ++
 drivers/staging/ccree/cc_fips.h  |   37 +
 drivers/staging/ccree/cc_hash.c  | 2297 +
 drivers/staging/ccree/cc_hash.h  |  114 ++
 drivers/staging/ccree/cc_host_regs.h |  142 ++
 drivers/staging/ccree/cc_hw_queue_defs.h |   32 +-
 drivers/staging/ccree/cc_ivgen.c |  280 +++
 drivers/staging/ccree/cc_ivgen.h |   55 +
 drivers/staging/ccree/cc_kernel_regs.h   |  167 ++
 drivers/staging/ccree/cc_lli_defs.h  |   17 +-
 drivers/staging/ccree/cc_pm.c|  123 ++
 drivers/staging/ccree/cc_pm.h|   57 +
 drivers/staging/ccree/cc_request_mgr.c   |  714 
 drivers/staging/ccree/cc_request_mgr.h   |   51 +
 drivers/staging/ccree/cc_sram_mgr.c  |  107 ++
 drivers/staging/ccree/cc_sram_mgr.h  |   65 +
 drivers/staging/ccree/dx_crys_kernel.h   |  180 --
 drivers/staging/ccree/dx_host.h  |  155 --
 drivers/staging/ccree/dx_reg_common.h|   26 -
 drivers/staging/ccree/hash_defs.h|   36 -
 drivers/staging/ccree/ssi_aead.c | 2720 --
 drivers/staging/ccree/ssi_aead.h |  122 --
 drivers/staging/ccree/ssi_buffer_mgr.c   | 1675 --
 drivers/staging/ccree/ssi_buffer_mgr.h   |   87 -
 drivers/staging/ccree/ssi_cipher.c   | 1182 -
 drivers/staging/ccree/ssi_cipher.h   |   87 -
 drivers/staging/ccree/ssi_driver.c   |  519 --
 drivers/staging/ccree/ssi_driver.h   |  201 ---
 drivers/staging/ccree/ssi_fips.c |  125 --
 drivers/staging/ccre

[PATCH v3 03/27] staging: ccree: fold reg common defines into driver

[Gilad Ben-Yossef]

Fold the 2 macro defined in dx_reg_common.h into the file they
are used in and delete the file.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/cc_crypto_ctx.h |  4 ++--
 drivers/staging/ccree/dx_reg_common.h | 13 -
 drivers/staging/ccree/ssi_driver.h|  5 +++--
 3 files changed, 5 insertions(+), 17 deletions(-)
 delete mode 100644 drivers/staging/ccree/dx_reg_common.h

diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index 02e14f3..eb16842 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -8,7 +8,7 @@
 
 /* context size */
 #ifndef CC_CTX_SIZE_LOG2
-#if (CC_SUPPORT_SHA > 256)
+#if (CC_DEV_SHA_MAX > 256)
 #define CC_CTX_SIZE_LOG2 8
 #else
 #define CC_CTX_SIZE_LOG2 7
@@ -59,7 +59,7 @@
 #define CC_SHA384_BLOCK_SIZE 128
 #define CC_SHA512_BLOCK_SIZE 128
 
-#if (CC_SUPPORT_SHA > 256)
+#if (CC_DEV_SHA_MAX > 256)
 #define CC_DIGEST_SIZE_MAX CC_SHA512_DIGEST_SIZE
 #define CC_HASH_BLOCK_SIZE_MAX CC_SHA512_BLOCK_SIZE /*1024b*/
 #else /* Only up to SHA256 */
diff --git a/drivers/staging/ccree/dx_reg_common.h 
b/drivers/staging/ccree/dx_reg_common.h
deleted file mode 100644
index 76c5539..000
--- a/drivers/staging/ccree/dx_reg_common.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
-
-#ifndef __CC_REG_COMMON_H__
-#define __CC_REG_COMMON_H__
-
-#define CC_DEV_SIGNATURE 0xDCC71200UL
-
-#define CC_HW_VERSION 0xef840015UL
-
-#define CC_DEV_SHA_MAX 512
-
-#endif /*__CC_REG_COMMON_H__*/
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index df805db..60c1cfd 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -27,8 +27,7 @@
 
 /* Registers definitions from shared/hw/ree_include */
 #include "dx_host.h"
-#include "dx_reg_common.h"
-#define CC_SUPPORT_SHA CC_DEV_SHA_MAX
+#define CC_DEV_SHA_MAX 512
 #include "cc_crypto_ctx.h"
 #include "cc_hw_queue_defs.h"
 #include "ssi_sram_mgr.h"
@@ -44,6 +43,8 @@ extern bool cc_dump_bytes;
 /* Maximum DMA mask supported by IP */
 #define DMA_BIT_MASK_LEN 48
 
+#define CC_DEV_SIGNATURE 0xDCC71200UL
+
 #define CC_AXI_IRQ_MASK ((1 << CC_AXIM_CFG_BRESPMASK_BIT_SHIFT) | \
  (1 << CC_AXIM_CFG_RRESPMASK_BIT_SHIFT) | \
  (1 << CC_AXIM_CFG_INFLTMASK_BIT_SHIFT) | \
-- 
2.7.4

[PATCH v3 07/27] staging: ccree: tag debugfs init/exit func properly

[Gilad Ben-Yossef]

The debugfs global init and exit functions were missing
__init and __exit tags, potentially wasting memory.
Fix it by properly tagging them.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/cc_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ccree/cc_debugfs.c 
b/drivers/staging/ccree/cc_debugfs.c
index ab2c986..72eb2b3 100644
--- a/drivers/staging/ccree/cc_debugfs.c
+++ b/drivers/staging/ccree/cc_debugfs.c
@@ -38,14 +38,14 @@ static struct debugfs_reg32 debug_regs[] = {
CC_DEBUG_REG(AXIM_MON_COMP),
 };
 
-int cc_debugfs_global_init(void)
+int __init cc_debugfs_global_init(void)
 {
cc_debugfs_dir = debugfs_create_dir("ccree", NULL);
 
return !cc_debugfs_dir;
 }
 
-void cc_debugfs_global_fini(void)
+void __exit cc_debugfs_global_fini(void)
 {
debugfs_remove(cc_debugfs_dir);
 }
-- 
2.7.4

[PATCH v3 04/27] staging: ccree: remove GFP_DMA flag from mem allocs

[Gilad Ben-Yossef]

Remove bogus GFP_DMA flag from memory allocations. ccree driver
does not operate over an ISA or similar limited bus.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_cipher.c |  2 +-
 drivers/staging/ccree/ssi_hash.c   | 15 ++-
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 6178d38..496eb19 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -166,7 +166,7 @@ static int cc_cipher_init(struct crypto_tfm *tfm)
ctx_p->drvdata = cc_alg->drvdata;
 
/* Allocate key buffer, cache line aligned */
-   ctx_p->user.key = kmalloc(max_key_buf_size, GFP_KERNEL | GFP_DMA);
+   ctx_p->user.key = kmalloc(max_key_buf_size, GFP_KERNEL);
if (!ctx_p->user.key)
return -ENOMEM;
 
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index 3c28904..f178ffa 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -132,29 +132,27 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
struct cc_hw_desc desc;
int rc = -ENOMEM;
 
-   state->buff0 = kzalloc(CC_MAX_HASH_BLCK_SIZE, GFP_KERNEL | GFP_DMA);
+   state->buff0 = kzalloc(CC_MAX_HASH_BLCK_SIZE, GFP_KERNEL);
if (!state->buff0)
goto fail0;
 
-   state->buff1 = kzalloc(CC_MAX_HASH_BLCK_SIZE, GFP_KERNEL | GFP_DMA);
+   state->buff1 = kzalloc(CC_MAX_HASH_BLCK_SIZE, GFP_KERNEL);
if (!state->buff1)
goto fail_buff0;
 
state->digest_result_buff = kzalloc(CC_MAX_HASH_DIGEST_SIZE,
-   GFP_KERNEL | GFP_DMA);
+   GFP_KERNEL);
if (!state->digest_result_buff)
goto fail_buff1;
 
-   state->digest_buff = kzalloc(ctx->inter_digestsize,
-GFP_KERNEL | GFP_DMA);
+   state->digest_buff = kzalloc(ctx->inter_digestsize, GFP_KERNEL);
if (!state->digest_buff)
goto fail_digest_result_buff;
 
dev_dbg(dev, "Allocated digest-buffer in context 
ctx->digest_buff=@%p\n",
state->digest_buff);
if (ctx->hw_mode != DRV_CIPHER_XCBC_MAC) {
-   state->digest_bytes_len = kzalloc(HASH_LEN_SIZE,
- GFP_KERNEL | GFP_DMA);
+   state->digest_bytes_len = kzalloc(HASH_LEN_SIZE, GFP_KERNEL);
if (!state->digest_bytes_len)
goto fail1;
 
@@ -164,8 +162,7 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
state->digest_bytes_len = NULL;
}
 
-   state->opad_digest_buff = kzalloc(ctx->inter_digestsize,
- GFP_KERNEL | GFP_DMA);
+   state->opad_digest_buff = kzalloc(ctx->inter_digestsize, GFP_KERNEL);
if (!state->opad_digest_buff)
goto fail2;
 
-- 
2.7.4

[PATCH v3 02/27] staging: ccree: fold hash defs into queue defs

[Gilad Ben-Yossef]

Fold the two remaining enum in hash defs into the queue defs
that are using them and delete the hash defs include file.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/cc_hw_queue_defs.h | 13 +
 drivers/staging/ccree/hash_defs.h| 23 ---
 drivers/staging/ccree/ssi_driver.h   |  1 -
 3 files changed, 13 insertions(+), 24 deletions(-)
 delete mode 100644 drivers/staging/ccree/hash_defs.h

diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h 
b/drivers/staging/ccree/cc_hw_queue_defs.h
index 52d32d1..bfc18b3 100644
--- a/drivers/staging/ccree/cc_hw_queue_defs.h
+++ b/drivers/staging/ccree/cc_hw_queue_defs.h
@@ -186,6 +186,19 @@ enum cc_hw_des_key_size {
END_OF_DES_KEYS = S32_MAX,
 };
 
+enum cc_hash_conf_pad {
+   HASH_PADDING_DISABLED = 0,
+   HASH_PADDING_ENABLED = 1,
+   HASH_DIGEST_RESULT_LITTLE_ENDIAN = 2,
+   HASH_CONFIG1_PADDING_RESERVE32 = S32_MAX,
+};
+
+enum cc_hash_cipher_pad {
+   DO_NOT_PAD = 0,
+   DO_PAD = 1,
+   HASH_CIPHER_DO_PADDING_RESERVE32 = S32_MAX,
+};
+
 /*/
 /* Descriptor packing macros */
 /*/
diff --git a/drivers/staging/ccree/hash_defs.h 
b/drivers/staging/ccree/hash_defs.h
deleted file mode 100644
index 92d5c10..000
--- a/drivers/staging/ccree/hash_defs.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
-
-#ifndef _HASH_DEFS_H_
-#define _HASH_DEFS_H_
-
-#include "cc_crypto_ctx.h"
-
-enum cc_hash_conf_pad {
-   HASH_PADDING_DISABLED = 0,
-   HASH_PADDING_ENABLED = 1,
-   HASH_DIGEST_RESULT_LITTLE_ENDIAN = 2,
-   HASH_CONFIG1_PADDING_RESERVE32 = S32_MAX,
-};
-
-enum cc_hash_cipher_pad {
-   DO_NOT_PAD = 0,
-   DO_PAD = 1,
-   HASH_CIPHER_DO_PADDING_RESERVE32 = S32_MAX,
-};
-
-#endif /*_HASH_DEFS_H_*/
-
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 7383a83..df805db 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -30,7 +30,6 @@
 #include "dx_reg_common.h"
 #define CC_SUPPORT_SHA CC_DEV_SHA_MAX
 #include "cc_crypto_ctx.h"
-#include "hash_defs.h"
 #include "cc_hw_queue_defs.h"
 #include "ssi_sram_mgr.h"
 
-- 
2.7.4

[PATCH v3 05/27] staging: ccree: pick alloc mem flags based on req flags

[Gilad Ben-Yossef]

The ccree driver was allocating memory using GFP_KERNEL flag
always, ignoring the flags set in the crypto request. Fix it
by choosing gfp flags based on crypto request flags.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c | 19 +++--
 drivers/staging/ccree/ssi_buffer_mgr.h |  6 ++--
 drivers/staging/ccree/ssi_cipher.c |  8 --
 drivers/staging/ccree/ssi_driver.h |  6 
 drivers/staging/ccree/ssi_hash.c   | 50 --
 5 files changed, 54 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index ece17caf..e85bb53 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -217,7 +217,7 @@ static int cc_render_sg_to_mlli(struct device *dev, struct 
scatterlist *sgl,
 }
 
 static int cc_generate_mlli(struct device *dev, struct buffer_array *sg_data,
-   struct mlli_params *mlli_params)
+   struct mlli_params *mlli_params, gfp_t flags)
 {
u32 *mlli_p;
u32 total_nents = 0, prev_total_nents = 0;
@@ -227,7 +227,7 @@ static int cc_generate_mlli(struct device *dev, struct 
buffer_array *sg_data,
 
/* Allocate memory from the pointed pool */
mlli_params->mlli_virt_addr =
-   dma_pool_alloc(mlli_params->curr_pool, GFP_KERNEL,
+   dma_pool_alloc(mlli_params->curr_pool, flags,
   &mlli_params->mlli_dma_addr);
if (!mlli_params->mlli_virt_addr) {
dev_err(dev, "dma_pool_alloc() failed\n");
@@ -483,7 +483,7 @@ void cc_unmap_blkcipher_request(struct device *dev, void 
*ctx,
 int cc_map_blkcipher_request(struct cc_drvdata *drvdata, void *ctx,
 unsigned int ivsize, unsigned int nbytes,
 void *info, struct scatterlist *src,
-struct scatterlist *dst)
+struct scatterlist *dst, gfp_t flags)
 {
struct blkcipher_req_ctx *req_ctx = (struct blkcipher_req_ctx *)ctx;
struct mlli_params *mlli_params = &req_ctx->mlli_params;
@@ -558,7 +558,7 @@ int cc_map_blkcipher_request(struct cc_drvdata *drvdata, 
void *ctx,
 
if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI) {
mlli_params->curr_pool = buff_mgr->mlli_buffs_pool;
-   rc = cc_generate_mlli(dev, &sg_data, mlli_params);
+   rc = cc_generate_mlli(dev, &sg_data, mlli_params, flags);
if (rc)
goto ablkcipher_exit;
}
@@ -1200,6 +1200,7 @@ int cc_map_aead_request(struct cc_drvdata *drvdata, 
struct aead_request *req)
u32 mapped_nents = 0;
u32 dummy = 0; /*used for the assoc data fragments */
u32 size_to_map = 0;
+   gfp_t flags = cc_gfp_flags(&req->base);
 
mlli_params->curr_pool = NULL;
sg_data.num_of_buffers = 0;
@@ -1366,7 +1367,7 @@ int cc_map_aead_request(struct cc_drvdata *drvdata, 
struct aead_request *req)
if (areq_ctx->assoc_buff_type == CC_DMA_BUF_MLLI ||
areq_ctx->data_buff_type == CC_DMA_BUF_MLLI) {
mlli_params->curr_pool = buff_mgr->mlli_buffs_pool;
-   rc = cc_generate_mlli(dev, &sg_data, mlli_params);
+   rc = cc_generate_mlli(dev, &sg_data, mlli_params, flags);
if (rc)
goto aead_map_failure;
 
@@ -1385,7 +1386,7 @@ int cc_map_aead_request(struct cc_drvdata *drvdata, 
struct aead_request *req)
 
 int cc_map_hash_request_final(struct cc_drvdata *drvdata, void *ctx,
  struct scatterlist *src, unsigned int nbytes,
- bool do_update)
+ bool do_update, gfp_t flags)
 {
struct ahash_req_ctx *areq_ctx = (struct ahash_req_ctx *)ctx;
struct device *dev = drvdata_to_dev(drvdata);
@@ -1445,7 +1446,7 @@ int cc_map_hash_request_final(struct cc_drvdata *drvdata, 
void *ctx,
/* add the src data to the sg_data */
cc_add_sg_entry(dev, &sg_data, areq_ctx->in_nents, src, nbytes,
0, true, &areq_ctx->mlli_nents);
-   if (cc_generate_mlli(dev, &sg_data, mlli_params))
+   if (cc_generate_mlli(dev, &sg_data, mlli_params, flags))
goto fail_unmap_din;
}
/* change the buffer index for the unmap function */
@@ -1466,7 +1467,7 @@ int cc_map_hash_request_final(struct cc_drvdata *drvdata, 
void *ctx,
 
 int cc_map_hash_request_update(struct cc_drvdata *drvdata, void *ctx,
   struct scatterlist *src, unsigned int nbytes,
-  unsigned int block_size)
+  unsigned int block_size, gfp_t flags)
 {
struct ahash_req_ctx *areq_ctx = (struct ahash_req_ctx *)ctx;
struct device *dev = drvdata_to_dev

[PATCH v3 08/27] staging: ccree: remove unused leftover field

[Gilad Ben-Yossef]

Remove the unused monitor_desc field.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_request_mgr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
b/drivers/staging/ccree/ssi_request_mgr.c
index 7686e14..e1c01da 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -32,7 +32,6 @@ struct cc_req_mgr_handle {
struct cc_hw_desc compl_desc;
u8 *dummy_comp_buff;
dma_addr_t dummy_comp_buff_dma;
-   struct cc_hw_desc monitor_desc;
 
 #ifdef COMP_IN_WQ
struct workqueue_struct *workq;
-- 
2.7.4

[PATCH v3 06/27] staging: ccree: copy larval digest from RAM

[Gilad Ben-Yossef]

The ccree driver was using a DMA operation to copy larval digest
from the ccree SRAM to RAM. Replace it with a simple memcpy.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_driver.c |   2 +
 drivers/staging/ccree/ssi_hash.c   | 121 -
 drivers/staging/ccree/ssi_hash.h   |   2 +
 3 files changed, 68 insertions(+), 57 deletions(-)

diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 3eabefb..b5df9b4 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -484,6 +484,8 @@ static int __init ccree_init(void)
 {
int ret;
 
+   cc_hash_global_init();
+
ret = cc_debugfs_global_init();
if (ret)
return ret;
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index 7a8a036..b51a1d4 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -41,10 +41,10 @@ static const u32 sha256_init[] = {
 #if (CC_DEV_SHA_MAX > 256)
 static const u32 digest_len_sha512_init[] = {
0x0080, 0x, 0x, 0x };
-static const u64 sha384_init[] = {
+static u64 sha384_init[] = {
SHA384_H7, SHA384_H6, SHA384_H5, SHA384_H4,
SHA384_H3, SHA384_H2, SHA384_H1, SHA384_H0 };
-static const u64 sha512_init[] = {
+static u64 sha512_init[] = {
SHA512_H7, SHA512_H6, SHA512_H5, SHA512_H4,
SHA512_H3, SHA512_H2, SHA512_H1, SHA512_H0 };
 #endif
@@ -55,6 +55,8 @@ static void cc_setup_xcbc(struct ahash_request *areq, struct 
cc_hw_desc desc[],
 static void cc_setup_cmac(struct ahash_request *areq, struct cc_hw_desc desc[],
  unsigned int *seq_size);
 
+static const void *cc_larval_digest(struct device *dev, u32 mode);
+
 struct cc_hash_alg {
struct list_head entry;
int hash_mode;
@@ -126,10 +128,6 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
  struct cc_hash_ctx *ctx, gfp_t flags)
 {
bool is_hmac = ctx->is_hmac;
-   cc_sram_addr_t larval_digest_addr =
-   cc_larval_digest_addr(ctx->drvdata, ctx->hash_mode);
-   struct cc_crypto_req cc_req = {};
-   struct cc_hw_desc desc;
int rc = -ENOMEM;
 
state->buff0 = kzalloc(CC_MAX_HASH_BLCK_SIZE, flags);
@@ -203,9 +201,6 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
   HASH_LEN_SIZE);
 #endif
}
-   dma_sync_single_for_device(dev, state->digest_buff_dma_addr,
-  ctx->inter_digestsize,
-  DMA_BIDIRECTIONAL);
 
if (ctx->hash_mode != DRV_HASH_NULL) {
dma_sync_single_for_cpu(dev,
@@ -216,22 +211,15 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
   ctx->opad_tmp_keys_buff, ctx->inter_digestsize);
}
} else { /*hash*/
-   /* Copy the initial digests if hash flow. The SRAM contains the
-* initial digests in the expected order for all SHA*
-*/
-   hw_desc_init(&desc);
-   set_din_sram(&desc, larval_digest_addr, ctx->inter_digestsize);
-   set_dout_dlli(&desc, state->digest_buff_dma_addr,
- ctx->inter_digestsize, NS_BIT, 0);
-   set_flow_mode(&desc, BYPASS);
+   /* Copy the initial digests if hash flow. */
+   const void *larval = cc_larval_digest(dev, ctx->hash_mode);
 
-   rc = send_request(ctx->drvdata, &cc_req, &desc, 1, 0);
-   if (rc) {
-   dev_err(dev, "send_request() failed (rc=%d)\n", rc);
-   goto fail4;
-   }
+   memcpy(state->digest_buff, larval, ctx->inter_digestsize);
}
 
+   dma_sync_single_for_device(dev, state->digest_buff_dma_addr,
+  ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+
if (ctx->hw_mode != DRV_CIPHER_XCBC_MAC) {
state->digest_bytes_len_dma_addr =
dma_map_single(dev, (void *)state->digest_bytes_len,
@@ -2003,11 +1991,7 @@ int cc_init_hash_sram(struct cc_drvdata *drvdata)
cc_sram_addr_t sram_buff_ofs = hash_handle->digest_len_sram_addr;
unsigned int larval_seq_len = 0;
struct cc_hw_desc larval_seq[CC_DIGEST_SIZE_MAX / sizeof(u32)];
-   struct device *dev = drvdata_to_dev(drvdata);
int rc = 0;
-#if (CC_DEV_SHA_MAX > 256)
-   int i;
-#endif
 
/* Copy-to-sram digest-len */
cc_set_sram_desc(digest_len_init, sram_buff_ofs,
@@ -2074,49 +2058,49 @@ int cc_init_hash_sram(struct cc_drvdata *drvdata)
larval_seq_len = 0;
 
 #if (CC_DEV_SHA_MAX > 256)
-   /* We are forced to swap each double-word larval before copying to
-   

[PATCH v3 09/27] staging: ccree: break send_request and fix ret val

[Gilad Ben-Yossef]

The send_request() function was handling both synchronous
and asynchronous invocations, but were not handling
the asynchronous case, which may be called in an atomic
context, properly as it was sleeping.

Start to fix the problem by breaking up the two use
cases to separate functions calling a common internal
service function and return error instead of sleeping
for the asynchronous case.

The next patch will complete the fix by implementing
proper backlog handling.

Fixes: abefd6741d ("staging: ccree: introduce CryptoCell HW driver").
Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_aead.c|   6 +-
 drivers/staging/ccree/ssi_cipher.c  |   3 +-
 drivers/staging/ccree/ssi_hash.c|  22 ++--
 drivers/staging/ccree/ssi_request_mgr.c | 180 ++--
 drivers/staging/ccree/ssi_request_mgr.h |  11 +-
 5 files changed, 128 insertions(+), 94 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 414098a..c2ae6f3 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -531,7 +531,7 @@ cc_get_plain_hmac_key(struct crypto_aead *tfm, const u8 
*key,
idx++;
}
 
-   rc = send_request(ctx->drvdata, &cc_req, desc, idx, 0);
+   rc = cc_send_sync_request(ctx->drvdata, &cc_req, desc, idx);
if (rc)
dev_err(dev, "send_request() failed (rc=%d)\n", rc);
 
@@ -630,7 +630,7 @@ cc_aead_setkey(struct crypto_aead *tfm, const u8 *key, 
unsigned int keylen)
/* STAT_PHASE_3: Submit sequence to HW */
 
if (seq_len > 0) { /* For CCM there is no sequence to setup the key */
-   rc = send_request(ctx->drvdata, &cc_req, desc, seq_len, 0);
+   rc = cc_send_sync_request(ctx->drvdata, &cc_req, desc, seq_len);
if (rc) {
dev_err(dev, "send_request() failed (rc=%d)\n", rc);
goto setkey_error;
@@ -2039,7 +2039,7 @@ static int cc_proc_aead(struct aead_request *req,
 
/* STAT_PHASE_3: Lock HW and push sequence */
 
-   rc = send_request(ctx->drvdata, &cc_req, desc, seq_len, 1);
+   rc = cc_send_request(ctx->drvdata, &cc_req, desc, seq_len, &req->base);
 
if (rc != -EINPROGRESS) {
dev_err(dev, "send_request() failed (rc=%d)\n", rc);
diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 933a452..beeed9c 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -717,7 +717,8 @@ static int cc_cipher_process(struct ablkcipher_request *req,
 
/* STAT_PHASE_3: Lock HW and push sequence */
 
-   rc = send_request(ctx_p->drvdata, &cc_req, desc, seq_len, 1);
+   rc = cc_send_request(ctx_p->drvdata, &cc_req, desc, seq_len,
+&req->base);
if (rc != -EINPROGRESS) {
/* Failed to send the request or request completed
 * synchronously
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index b51a1d4..b05fd40 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -532,7 +532,7 @@ static int cc_hash_digest(struct ahash_request *req)
cc_set_endianity(ctx->hash_mode, &desc[idx]);
idx++;
 
-   rc = send_request(ctx->drvdata, &cc_req, desc, idx, 1);
+   rc = cc_send_request(ctx->drvdata, &cc_req, desc, idx, &req->base);
if (rc != -EINPROGRESS) {
dev_err(dev, "send_request() failed (rc=%d)\n", rc);
cc_unmap_hash_request(dev, state, src, true);
@@ -620,7 +620,7 @@ static int cc_hash_update(struct ahash_request *req)
set_setup_mode(&desc[idx], SETUP_WRITE_STATE1);
idx++;
 
-   rc = send_request(ctx->drvdata, &cc_req, desc, idx, 1);
+   rc = cc_send_request(ctx->drvdata, &cc_req, desc, idx, &req->base);
if (rc != -EINPROGRESS) {
dev_err(dev, "send_request() failed (rc=%d)\n", rc);
cc_unmap_hash_request(dev, state, src, true);
@@ -741,7 +741,7 @@ static int cc_hash_finup(struct ahash_request *req)
set_cipher_mode(&desc[idx], ctx->hw_mode);
idx++;
 
-   rc = send_request(ctx->drvdata, &cc_req, desc, idx, 1);
+   rc = cc_send_request(ctx->drvdata, &cc_req, desc, idx, &req->base);
if (rc != -EINPROGRESS) {
dev_err(dev, "send_request() failed (rc=%d)\n", rc);
cc_unmap_hash_request(dev, state, src, true);
@@ -873,7 +873,7 @@ static int cc_hash_final(struct ahash_request *req)
set_cipher_mode(&desc[idx], ctx->hw_mode);
idx++;
 
-   rc = send_request(ctx->drvdata, &cc_req, desc, idx, 1);
+   rc = cc_send_request(ctx->drvdata, &cc_req, desc, idx, &req->base);
if (rc != -EINPROGRESS) {
dev_err(dev, "send_request() failed (rc=%d)\n", rc);
cc_unmap_hash_request(dev, state, src, true);
@@ -1014,7 +

[PATCH v3 13/27] staging: ccree: check DMA pool buf !NULL before free

[Gilad Ben-Yossef]

If we ran out of DMA pool buffers, we get into the unmap
code path with a NULL before. Deal with this by checking
the virtual mapping is not NULL.

Cc: sta...@vger.kernel.org
Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index e85bb53..78288ed 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -465,7 +465,8 @@ void cc_unmap_blkcipher_request(struct device *dev, void 
*ctx,
 DMA_TO_DEVICE);
}
/* Release pool */
-   if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI) {
+   if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI &&
+   req_ctx->mlli_params.mlli_virt_addr) {
dma_pool_free(req_ctx->mlli_params.curr_pool,
  req_ctx->mlli_params.mlli_virt_addr,
  req_ctx->mlli_params.mlli_dma_addr);
-- 
2.7.4

[PATCH v3 11/27] stating: ccree: revert "staging: ccree: fix leak of import() after init()"

[Gilad Ben-Yossef]

This reverts commit c5f39d07860c ("staging: ccree: fix leak of import()
after init()") and commit aece09024414 ("staging: ccree: Uninitialized
return in ssi_ahash_import()").

This is the wrong solution and ends up relying on uninitialized memory,
although it was not obvious to me at the time.

Cc: sta...@vger.kernel.org
Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_hash.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index ff05ac8..ee7370c 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -1673,7 +1673,7 @@ static int cc_hash_import(struct ahash_request *req, 
const void *in)
struct device *dev = drvdata_to_dev(ctx->drvdata);
struct ahash_req_ctx *state = ahash_request_ctx(req);
u32 tmp;
-   int rc = 0;
+   int rc;
 
memcpy(&tmp, in, sizeof(u32));
if (tmp != CC_EXPORT_MAGIC) {
@@ -1682,12 +1682,9 @@ static int cc_hash_import(struct ahash_request *req, 
const void *in)
}
in += sizeof(u32);
 
-   /* call init() to allocate bufs if the user hasn't */
-   if (!state->digest_buff) {
-   rc = cc_hash_init(req);
-   if (rc)
-   goto out;
-   }
+   rc = cc_hash_init(req);
+   if (rc)
+   goto out;
 
dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr,
ctx->inter_digestsize, DMA_BIDIRECTIONAL);
-- 
2.7.4

[PATCH v3 10/27] staging: ccree: add backlog processing

[Gilad Ben-Yossef]

Crypto API tfm providers are required to provide a backlog
service, if so indicated, that queues up requests in the case
of the provider being busy and processing them later.

The ccree driver did not provide this facility. Add it now.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_aead.c|  26 +++---
 drivers/staging/ccree/ssi_cipher.c  |  13 ++-
 drivers/staging/ccree/ssi_driver.h  |   2 +-
 drivers/staging/ccree/ssi_hash.c|  28 +++
 drivers/staging/ccree/ssi_request_mgr.c | 136 ++--
 5 files changed, 163 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index c2ae6f3..6f41a00 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -211,19 +211,21 @@ static int cc_aead_init(struct crypto_aead *tfm)
return -ENOMEM;
 }
 
-static void cc_aead_complete(struct device *dev, void *cc_req)
+static void cc_aead_complete(struct device *dev, void *cc_req, int err)
 {
struct aead_request *areq = (struct aead_request *)cc_req;
struct aead_req_ctx *areq_ctx = aead_request_ctx(areq);
struct crypto_aead *tfm = crypto_aead_reqtfm(cc_req);
struct cc_aead_ctx *ctx = crypto_aead_ctx(tfm);
-   int err = 0;
 
cc_unmap_aead_request(dev, areq);
 
/* Restore ordinary iv pointer */
areq->iv = areq_ctx->backup_iv;
 
+   if (err)
+   goto done;
+
if (areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) {
if (memcmp(areq_ctx->mac_buf, areq_ctx->icv_virt_addr,
   ctx->authsize) != 0) {
@@ -258,7 +260,7 @@ static void cc_aead_complete(struct device *dev, void 
*cc_req)
   CCM_BLOCK_IV_OFFSET, CCM_BLOCK_IV_SIZE);
}
}
-
+done:
aead_request_complete(areq, err);
 }
 
@@ -2041,7 +2043,7 @@ static int cc_proc_aead(struct aead_request *req,
 
rc = cc_send_request(ctx->drvdata, &cc_req, desc, seq_len, &req->base);
 
-   if (rc != -EINPROGRESS) {
+   if (rc != -EINPROGRESS && rc != -EBUSY) {
dev_err(dev, "send_request() failed (rc=%d)\n", rc);
cc_unmap_aead_request(dev, req);
}
@@ -2063,7 +2065,7 @@ static int cc_aead_encrypt(struct aead_request *req)
areq_ctx->plaintext_authenticate_only = false;
 
rc = cc_proc_aead(req, DRV_CRYPTO_DIRECTION_ENCRYPT);
-   if (rc != -EINPROGRESS)
+   if (rc != -EINPROGRESS && rc != -EBUSY)
req->iv = areq_ctx->backup_iv;
 
return rc;
@@ -2092,7 +2094,7 @@ static int cc_rfc4309_ccm_encrypt(struct aead_request 
*req)
cc_proc_rfc4309_ccm(req);
 
rc = cc_proc_aead(req, DRV_CRYPTO_DIRECTION_ENCRYPT);
-   if (rc != -EINPROGRESS)
+   if (rc != -EINPROGRESS && rc != -EBUSY)
req->iv = areq_ctx->backup_iv;
 out:
return rc;
@@ -2111,7 +2113,7 @@ static int cc_aead_decrypt(struct aead_request *req)
areq_ctx->plaintext_authenticate_only = false;
 
rc = cc_proc_aead(req, DRV_CRYPTO_DIRECTION_DECRYPT);
-   if (rc != -EINPROGRESS)
+   if (rc != -EINPROGRESS && rc != -EBUSY)
req->iv = areq_ctx->backup_iv;
 
return rc;
@@ -2138,7 +2140,7 @@ static int cc_rfc4309_ccm_decrypt(struct aead_request 
*req)
cc_proc_rfc4309_ccm(req);
 
rc = cc_proc_aead(req, DRV_CRYPTO_DIRECTION_DECRYPT);
-   if (rc != -EINPROGRESS)
+   if (rc != -EINPROGRESS && rc != -EBUSY)
req->iv = areq_ctx->backup_iv;
 
 out:
@@ -2257,7 +2259,7 @@ static int cc_rfc4106_gcm_encrypt(struct aead_request 
*req)
areq_ctx->is_gcm4543 = true;
 
rc = cc_proc_aead(req, DRV_CRYPTO_DIRECTION_ENCRYPT);
-   if (rc != -EINPROGRESS)
+   if (rc != -EINPROGRESS && rc != -EBUSY)
req->iv = areq_ctx->backup_iv;
 out:
return rc;
@@ -2281,7 +2283,7 @@ static int cc_rfc4543_gcm_encrypt(struct aead_request 
*req)
areq_ctx->is_gcm4543 = true;
 
rc = cc_proc_aead(req, DRV_CRYPTO_DIRECTION_ENCRYPT);
-   if (rc != -EINPROGRESS)
+   if (rc != -EINPROGRESS && rc != -EBUSY)
req->iv = areq_ctx->backup_iv;
 
return rc;
@@ -2312,7 +2314,7 @@ static int cc_rfc4106_gcm_decrypt(struct aead_request 
*req)
areq_ctx->is_gcm4543 = true;
 
rc = cc_proc_aead(req, DRV_CRYPTO_DIRECTION_DECRYPT);
-   if (rc != -EINPROGRESS)
+   if (rc != -EINPROGRESS && rc != -EBUSY)
req->iv = areq_ctx->backup_iv;
 out:
return rc;
@@ -2336,7 +2338,7 @@ static int cc_rfc4543_gcm_decrypt(struct aead_request 
*req)
areq_ctx->is_gcm4543 = true;
 
rc = cc_proc_aead(req, DRV_CRYPTO_DIRECTION_DECRYPT);
-   if (rc != -EINPROGRESS)
+   if (rc != -EINPROGRESS && rc != -EBUSY)
req->iv = areq_ctx->backup_iv;
 
return rc;
diff --git a/drivers/stagin

[PATCH v3 12/27] staging: ccree: failing the suspend is not an error

[Gilad Ben-Yossef]

PM suspend returning a none zero value is not an error. It simply
indicates a suspend is not advised right now so don't treat it as
an error.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_request_mgr.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
b/drivers/staging/ccree/ssi_request_mgr.c
index 1d13756..ff751d3 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -598,9 +598,6 @@ static void proc_completions(struct cc_drvdata *drvdata)
drvdata->request_mgr_handle;
unsigned int *tail = &request_mgr_handle->req_queue_tail;
unsigned int *head = &request_mgr_handle->req_queue_head;
-#if defined(CONFIG_PM)
-   int rc = 0;
-#endif
 
while (request_mgr_handle->axi_completed) {
request_mgr_handle->axi_completed--;
@@ -625,10 +622,7 @@ static void proc_completions(struct cc_drvdata *drvdata)
dev_dbg(dev, "Request completed. axi_completed=%d\n",
request_mgr_handle->axi_completed);
 #if defined(CONFIG_PM)
-   rc = cc_pm_put_suspend(dev);
-   if (rc)
-   dev_err(dev, "Failed to set runtime suspension %d\n",
-   rc);
+   cc_pm_put_suspend(dev);
 #endif
}
 }
-- 
2.7.4

[PATCH v3 17/27] staging: ccree: use array for double buffer

[Gilad Ben-Yossef]

The ccree hash code is using a double buffer to hold data
for processing but manages the buffers and their associated
data count in two separate fields and uses a predicate to
chose which to use.

Move to using a proper 2 members array for a much cleaner code.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c | 21 +++-
 drivers/staging/ccree/ssi_hash.c   | 36 --
 drivers/staging/ccree/ssi_hash.h   | 26 
 3 files changed, 46 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 0f71264..684070d 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -1391,10 +1391,8 @@ int cc_map_hash_request_final(struct cc_drvdata 
*drvdata, void *ctx,
 {
struct ahash_req_ctx *areq_ctx = (struct ahash_req_ctx *)ctx;
struct device *dev = drvdata_to_dev(drvdata);
-   u8 *curr_buff = areq_ctx->buff_index ? areq_ctx->buff1 :
-   areq_ctx->buff0;
-   u32 *curr_buff_cnt = areq_ctx->buff_index ? &areq_ctx->buff1_cnt :
-   &areq_ctx->buff0_cnt;
+   u8 *curr_buff = cc_hash_buf(areq_ctx);
+   u32 *curr_buff_cnt = cc_hash_buf_cnt(areq_ctx);
struct mlli_params *mlli_params = &areq_ctx->mlli_params;
struct buffer_array sg_data;
struct buff_mgr_handle *buff_mgr = drvdata->buff_mgr_handle;
@@ -1472,14 +1470,10 @@ int cc_map_hash_request_update(struct cc_drvdata 
*drvdata, void *ctx,
 {
struct ahash_req_ctx *areq_ctx = (struct ahash_req_ctx *)ctx;
struct device *dev = drvdata_to_dev(drvdata);
-   u8 *curr_buff = areq_ctx->buff_index ? areq_ctx->buff1 :
-   areq_ctx->buff0;
-   u32 *curr_buff_cnt = areq_ctx->buff_index ? &areq_ctx->buff1_cnt :
-   &areq_ctx->buff0_cnt;
-   u8 *next_buff = areq_ctx->buff_index ? areq_ctx->buff0 :
-   areq_ctx->buff1;
-   u32 *next_buff_cnt = areq_ctx->buff_index ? &areq_ctx->buff0_cnt :
-   &areq_ctx->buff1_cnt;
+   u8 *curr_buff = cc_hash_buf(areq_ctx);
+   u32 *curr_buff_cnt = cc_hash_buf_cnt(areq_ctx);
+   u8 *next_buff = cc_next_buf(areq_ctx);
+   u32 *next_buff_cnt = cc_next_buf_cnt(areq_ctx);
struct mlli_params *mlli_params = &areq_ctx->mlli_params;
unsigned int update_data_len;
u32 total_in_len = nbytes + *curr_buff_cnt;
@@ -1585,8 +1579,7 @@ void cc_unmap_hash_request(struct device *dev, void *ctx,
   struct scatterlist *src, bool do_revert)
 {
struct ahash_req_ctx *areq_ctx = (struct ahash_req_ctx *)ctx;
-   u32 *prev_len = areq_ctx->buff_index ?  &areq_ctx->buff0_cnt :
-   &areq_ctx->buff1_cnt;
+   u32 *prev_len = cc_next_buf_cnt(areq_ctx);
 
/*In case a pool was set, a table was
 *allocated and should be released
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index efea792..5ea095a 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -129,12 +129,12 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
bool is_hmac = ctx->is_hmac;
int rc = -ENOMEM;
 
-   state->buff0 = kzalloc(CC_MAX_HASH_BLCK_SIZE, flags);
-   if (!state->buff0)
+   state->buffers[0] = kzalloc(CC_MAX_HASH_BLCK_SIZE, flags);
+   if (!state->buffers[0])
goto fail0;
 
-   state->buff1 = kzalloc(CC_MAX_HASH_BLCK_SIZE, flags);
-   if (!state->buff1)
+   state->buffers[1] = kzalloc(CC_MAX_HASH_BLCK_SIZE, flags);
+   if (!state->buffers[1])
goto fail_buff0;
 
state->digest_result_buff = kzalloc(CC_MAX_HASH_DIGEST_SIZE, flags);
@@ -252,8 +252,8 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
} else {
state->opad_digest_dma_addr = 0;
}
-   state->buff0_cnt = 0;
-   state->buff1_cnt = 0;
+   state->buf_cnt[0] = 0;
+   state->buf_cnt[1] = 0;
state->buff_index = 0;
state->mlli_params.curr_pool = NULL;
 
@@ -281,11 +281,11 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
kfree(state->digest_result_buff);
state->digest_result_buff = NULL;
 fail_buff1:
-   kfree(state->buff1);
-   state->buff1 = NULL;
+   kfree(state->buffers[1]);
+   state->buffers[1] = NULL;
 fail_buff0:
-   kfree(state->buff0);
-   state->buff0 = NULL;
+   kfree(state->buffers[0]);
+   state->buffers[0] = NULL;
 fail0:
return rc;
 }
@@ -319,8 +319,8 @@ static void cc_unmap_req(struct device *dev, struct 
ahash_req_ctx *state,
kfree(state->digest_bytes_len);
kfree(state->digest_buff);
kfree(state->digest_result_buff);
-   kfree(state->

[PATCH v3 15/27] staging: ccree: use Makefile to include PM code

[Gilad Ben-Yossef]

Replace ugly ifdefs with some inline macros and Makefile magic
for optionally including power management related code for
better readability.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Makefile  |  3 ++-
 drivers/staging/ccree/ssi_pm.c  |  9 +---
 drivers/staging/ccree/ssi_pm.h  | 39 +++--
 drivers/staging/ccree/ssi_request_mgr.c | 18 ++-
 4 files changed, 37 insertions(+), 32 deletions(-)

diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index bb47144..c107e25 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_buffer_mgr.o ssi_request_mgr.o ssi_cipher.o 
ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o
+ccree-y := ssi_driver.o ssi_buffer_mgr.o ssi_request_mgr.o ssi_cipher.o 
ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o
 ccree-$(CONFIG_CRYPTO_FIPS) += ssi_fips.o
 ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o
+ccree-$(CONFIG_PM) += ssi_pm.o
diff --git a/drivers/staging/ccree/ssi_pm.c b/drivers/staging/ccree/ssi_pm.c
index 3d9d00b..3a8d91c 100644
--- a/drivers/staging/ccree/ssi_pm.c
+++ b/drivers/staging/ccree/ssi_pm.c
@@ -14,8 +14,6 @@
 #include "ssi_hash.h"
 #include "ssi_pm.h"
 
-#if defined(CONFIG_PM)
-
 #define POWER_DOWN_ENABLE 0x01
 #define POWER_DOWN_DISABLE 0x00
 
@@ -103,12 +101,9 @@ int cc_pm_put_suspend(struct device *dev)
return rc;
 }
 
-#endif
-
 int cc_pm_init(struct cc_drvdata *drvdata)
 {
int rc = 0;
-#if defined(CONFIG_PM)
struct device *dev = drvdata_to_dev(drvdata);
 
/* must be before the enabling to avoid resdundent suspending */
@@ -120,13 +115,11 @@ int cc_pm_init(struct cc_drvdata *drvdata)
return rc;
/* enable the PM module*/
pm_runtime_enable(dev);
-#endif
+
return rc;
 }
 
 void cc_pm_fini(struct cc_drvdata *drvdata)
 {
-#if defined(CONFIG_PM)
pm_runtime_disable(drvdata_to_dev(drvdata));
-#endif
 }
diff --git a/drivers/staging/ccree/ssi_pm.h b/drivers/staging/ccree/ssi_pm.h
index 87bc389..f603255 100644
--- a/drivers/staging/ccree/ssi_pm.h
+++ b/drivers/staging/ccree/ssi_pm.h
@@ -11,21 +11,46 @@
 
 #define CC_SUSPEND_TIMEOUT 3000
 
-int cc_pm_init(struct cc_drvdata *drvdata);
-
-void cc_pm_fini(struct cc_drvdata *drvdata);
-
 #if defined(CONFIG_PM)
 
 extern const struct dev_pm_ops ccree_pm;
 
+int cc_pm_init(struct cc_drvdata *drvdata);
+void cc_pm_fini(struct cc_drvdata *drvdata);
 int cc_pm_suspend(struct device *dev);
-
 int cc_pm_resume(struct device *dev);
-
 int cc_pm_get(struct device *dev);
-
 int cc_pm_put_suspend(struct device *dev);
+
+#else
+
+static inline int cc_pm_init(struct cc_drvdata *drvdata)
+{
+   return 0;
+}
+
+static inline void cc_pm_fini(struct cc_drvdata *drvdata) {}
+
+static inline int cc_pm_suspend(struct device *dev)
+{
+   return 0;
+}
+
+static inline int cc_pm_resume(struct device *dev)
+{
+   return 0;
+}
+
+static inline int cc_pm_get(struct device *dev)
+{
+   return 0;
+}
+
+static inline int cc_pm_put_suspend(struct device *dev)
+{
+   return 0;
+}
+
 #endif
 
 #endif /*__POWER_MGR_H__*/
diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
b/drivers/staging/ccree/ssi_request_mgr.c
index ff751d3..78f25e5 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -46,9 +46,7 @@ struct cc_req_mgr_handle {
 #else
struct tasklet_struct comptask;
 #endif
-#if defined(CONFIG_PM)
bool is_runtime_suspended;
-#endif
 };
 
 struct cc_bl_item {
@@ -404,9 +402,7 @@ static void cc_proc_backlog(struct cc_drvdata *drvdata)
spin_unlock(&mgr->hw_lock);
 
if (rc != -EINPROGRESS) {
-#if defined(CONFIG_PM)
cc_pm_put_suspend(dev);
-#endif
creq->user_cb(dev, req, rc);
}
 
@@ -432,13 +428,12 @@ int cc_send_request(struct cc_drvdata *drvdata, struct 
cc_crypto_req *cc_req,
gfp_t flags = cc_gfp_flags(req);
struct cc_bl_item *bli;
 
-#if defined(CONFIG_PM)
rc = cc_pm_get(dev);
if (rc) {
dev_err(dev, "ssi_power_mgr_runtime_get returned %x\n", rc);
return rc;
}
-#endif
+
spin_lock_bh(&mgr->hw_lock);
rc = cc_queues_status(drvdata, mgr, total_len);
 
@@ -452,9 +447,7 @@ int cc_send_request(struct cc_drvdata *drvdata, struct 
cc_crypto_req *cc_req,
 
bli = kmalloc(sizeof(*bli), flags);
if (!bli) {
-#if defined(CONFIG_PM)
cc_pm_put_suspend(dev);
-#endif
return -ENOMEM;
}
 
@@ -486,13 +479,12 @@ int cc_send_sync_request(struct cc_drvdata *drvdata,
cc_req->user_cb = request_mgr_complete;
cc_req->user_arg = &cc_req->seq_compl;
 
-#if defined(CONFIG_PM)
   

[PATCH v3 14/27] staging: ccree: handle end of sg list gracefully

[Gilad Ben-Yossef]

If we are asked for number of entries of an offset bigger than the
sg list we should not crash.

Cc: sta...@vger.kernel.org
Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 78288ed..0f71264 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -94,7 +94,7 @@ static unsigned int cc_get_sgl_nents(struct device *dev,
 {
unsigned int nents = 0;
 
-   while (nbytes) {
+   while (nbytes && sg_list) {
if (sg_list->length) {
nents++;
/* get the number of bytes in the last entry */
-- 
2.7.4

[PATCH v3 18/27] staging: ccree: allocate hash bufs inside req ctx

[Gilad Ben-Yossef]

Move to allocating the buffers needed for requests as part of
the request structure instead of malloc'ing each one on it's
own, making for simpler (and more efficient) code.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_hash.c | 68 
 drivers/staging/ccree/ssi_hash.h | 12 +++
 2 files changed, 12 insertions(+), 68 deletions(-)

diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index 5ea095a..b557db2 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -108,7 +108,7 @@ static int cc_map_result(struct device *dev, struct 
ahash_req_ctx *state,
 unsigned int digestsize)
 {
state->digest_result_dma_addr =
-   dma_map_single(dev, (void *)state->digest_result_buff,
+   dma_map_single(dev, state->digest_result_buff,
   digestsize,
   DMA_BIDIRECTIONAL);
if (dma_mapping_error(dev, state->digest_result_dma_addr)) {
@@ -129,49 +129,15 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
bool is_hmac = ctx->is_hmac;
int rc = -ENOMEM;
 
-   state->buffers[0] = kzalloc(CC_MAX_HASH_BLCK_SIZE, flags);
-   if (!state->buffers[0])
-   goto fail0;
-
-   state->buffers[1] = kzalloc(CC_MAX_HASH_BLCK_SIZE, flags);
-   if (!state->buffers[1])
-   goto fail_buff0;
-
-   state->digest_result_buff = kzalloc(CC_MAX_HASH_DIGEST_SIZE, flags);
-   if (!state->digest_result_buff)
-   goto fail_buff1;
-
-   state->digest_buff = kzalloc(ctx->inter_digestsize, flags);
-   if (!state->digest_buff)
-   goto fail_digest_result_buff;
-
-   dev_dbg(dev, "Allocated digest-buffer in context 
ctx->digest_buff=@%p\n",
-   state->digest_buff);
-   if (ctx->hw_mode != DRV_CIPHER_XCBC_MAC) {
-   state->digest_bytes_len = kzalloc(HASH_LEN_SIZE, flags);
-   if (!state->digest_bytes_len)
-   goto fail1;
-
-   dev_dbg(dev, "Allocated digest-bytes-len in context 
state->>digest_bytes_len=@%p\n",
-   state->digest_bytes_len);
-   } else {
-   state->digest_bytes_len = NULL;
-   }
-
-   state->opad_digest_buff = kzalloc(ctx->inter_digestsize, flags);
-   if (!state->opad_digest_buff)
-   goto fail2;
-
-   dev_dbg(dev, "Allocated opad-digest-buffer in context 
state->digest_bytes_len=@%p\n",
-   state->opad_digest_buff);
+   memset(state, 0, sizeof(*state));
 
state->digest_buff_dma_addr =
-   dma_map_single(dev, (void *)state->digest_buff,
+   dma_map_single(dev, state->digest_buff,
   ctx->inter_digestsize, DMA_BIDIRECTIONAL);
if (dma_mapping_error(dev, state->digest_buff_dma_addr)) {
dev_err(dev, "Mapping digest len %d B at va=%pK for DMA 
failed\n",
ctx->inter_digestsize, state->digest_buff);
-   goto fail3;
+   goto fail0;
}
dev_dbg(dev, "Mapped digest %d B at va=%pK to dma=%pad\n",
ctx->inter_digestsize, state->digest_buff,
@@ -221,7 +187,7 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
 
if (ctx->hw_mode != DRV_CIPHER_XCBC_MAC) {
state->digest_bytes_len_dma_addr =
-   dma_map_single(dev, (void *)state->digest_bytes_len,
+   dma_map_single(dev, state->digest_bytes_len,
   HASH_LEN_SIZE, DMA_BIDIRECTIONAL);
if (dma_mapping_error(dev, state->digest_bytes_len_dma_addr)) {
dev_err(dev, "Mapping digest len %u B at va=%pK for DMA 
failed\n",
@@ -237,7 +203,7 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
 
if (is_hmac && ctx->hash_mode != DRV_HASH_NULL) {
state->opad_digest_dma_addr =
-   dma_map_single(dev, (void *)state->opad_digest_buff,
+   dma_map_single(dev, state->opad_digest_buff,
   ctx->inter_digestsize,
   DMA_BIDIRECTIONAL);
if (dma_mapping_error(dev, state->opad_digest_dma_addr)) {
@@ -271,21 +237,6 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
 ctx->inter_digestsize, DMA_BIDIRECTIONAL);
state->digest_buff_dma_addr = 0;
}
-fail3:
-   kfree(state->opad_digest_buff);
-fail2:
-   kfree(state->digest_bytes_len);
-fail1:
-kfree(state->digest_buff);
-fail_digest_result_buff:
-   kfree(state->digest_result_buff);
-   state->digest_result_buff = NULL;
-fail_buff1:
-   kfree(state->buffers[1]);
-   state->buffers[1] = NULL;
-

[PATCH v3 16/27] staging: ccree: remove unused field

[Gilad Ben-Yossef]

Remove unused struct field.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_hash.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index ee7370c..efea792 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -23,7 +23,6 @@ struct cc_hash_handle {
cc_sram_addr_t digest_len_sram_addr; /* const value in SRAM*/
cc_sram_addr_t larval_digest_sram_addr;   /* const value in SRAM */
struct list_head hash_list;
-   struct completion init_comp;
 };
 
 static const u32 digest_len_init[] = {
-- 
2.7.4

[PATCH v3 21/27] staging: ccree: fold common code into service func

[Gilad Ben-Yossef]

Fold common code in hash call into service functions.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_hash.c | 339 ++-
 1 file changed, 116 insertions(+), 223 deletions(-)

diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index c04b335..57031c7 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -319,6 +319,84 @@ static void cc_hash_complete(struct device *dev, void 
*cc_req, int err)
req->base.complete(&req->base, err);
 }
 
+static int cc_fin_result(struct cc_hw_desc *desc, struct ahash_request *req,
+int idx)
+{
+   struct ahash_req_ctx *state = ahash_request_ctx(req);
+   struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
+   struct cc_hash_ctx *ctx = crypto_ahash_ctx(tfm);
+   u32 digestsize = crypto_ahash_digestsize(tfm);
+
+   /* Get final MAC result */
+   hw_desc_init(&desc[idx]);
+   set_cipher_mode(&desc[idx], ctx->hw_mode);
+   /* TODO */
+   set_dout_dlli(&desc[idx], state->digest_result_dma_addr, digestsize,
+ NS_BIT, 1);
+   set_queue_last_ind(&desc[idx]);
+   set_flow_mode(&desc[idx], S_HASH_to_DOUT);
+   set_setup_mode(&desc[idx], SETUP_WRITE_STATE0);
+   set_cipher_config1(&desc[idx], HASH_PADDING_DISABLED);
+   cc_set_endianity(ctx->hash_mode, &desc[idx]);
+   idx++;
+
+   return idx;
+}
+
+static int cc_fin_hmac(struct cc_hw_desc *desc, struct ahash_request *req,
+  int idx)
+{
+   struct ahash_req_ctx *state = ahash_request_ctx(req);
+   struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
+   struct cc_hash_ctx *ctx = crypto_ahash_ctx(tfm);
+   u32 digestsize = crypto_ahash_digestsize(tfm);
+
+   /* store the hash digest result in the context */
+   hw_desc_init(&desc[idx]);
+   set_cipher_mode(&desc[idx], ctx->hw_mode);
+   set_dout_dlli(&desc[idx], state->digest_buff_dma_addr, digestsize,
+ NS_BIT, 0);
+   set_flow_mode(&desc[idx], S_HASH_to_DOUT);
+   cc_set_endianity(ctx->hash_mode, &desc[idx]);
+   set_setup_mode(&desc[idx], SETUP_WRITE_STATE0);
+   idx++;
+
+   /* Loading hash opad xor key state */
+   hw_desc_init(&desc[idx]);
+   set_cipher_mode(&desc[idx], ctx->hw_mode);
+   set_din_type(&desc[idx], DMA_DLLI, state->opad_digest_dma_addr,
+ctx->inter_digestsize, NS_BIT);
+   set_flow_mode(&desc[idx], S_DIN_to_HASH);
+   set_setup_mode(&desc[idx], SETUP_LOAD_STATE0);
+   idx++;
+
+   /* Load the hash current length */
+   hw_desc_init(&desc[idx]);
+   set_cipher_mode(&desc[idx], ctx->hw_mode);
+   set_din_sram(&desc[idx],
+cc_digest_len_addr(ctx->drvdata, ctx->hash_mode),
+HASH_LEN_SIZE);
+   set_cipher_config1(&desc[idx], HASH_PADDING_ENABLED);
+   set_flow_mode(&desc[idx], S_DIN_to_HASH);
+   set_setup_mode(&desc[idx], SETUP_LOAD_KEY0);
+   idx++;
+
+   /* Memory Barrier: wait for IPAD/OPAD axi write to complete */
+   hw_desc_init(&desc[idx]);
+   set_din_no_dma(&desc[idx], 0, 0xf0);
+   set_dout_no_dma(&desc[idx], 0, 0, 1);
+   idx++;
+
+   /* Perform HASH update */
+   hw_desc_init(&desc[idx]);
+   set_din_type(&desc[idx], DMA_DLLI, state->digest_buff_dma_addr,
+digestsize, NS_BIT);
+   set_flow_mode(&desc[idx], DIN_HASH);
+   idx++;
+
+   return idx;
+}
+
 static int cc_hash_digest(struct ahash_request *req)
 {
struct ahash_req_ctx *state = ahash_request_ctx(req);
@@ -414,62 +492,10 @@ static int cc_hash_digest(struct ahash_request *req)
set_cipher_do(&desc[idx], DO_PAD);
idx++;
 
-   /* store the hash digest result in the context */
-   hw_desc_init(&desc[idx]);
-   set_cipher_mode(&desc[idx], ctx->hw_mode);
-   set_dout_dlli(&desc[idx], state->digest_buff_dma_addr,
- digestsize, NS_BIT, 0);
-   set_flow_mode(&desc[idx], S_HASH_to_DOUT);
-   cc_set_endianity(ctx->hash_mode, &desc[idx]);
-   set_setup_mode(&desc[idx], SETUP_WRITE_STATE0);
-   idx++;
-
-   /* Loading hash opad xor key state */
-   hw_desc_init(&desc[idx]);
-   set_cipher_mode(&desc[idx], ctx->hw_mode);
-   set_din_type(&desc[idx], DMA_DLLI, state->opad_digest_dma_addr,
-ctx->inter_digestsize, NS_BIT);
-   set_flow_mode(&desc[idx], S_DIN_to_HASH);
-   set_setup_mode(&desc[idx], SETUP_LOAD_STATE0);
-   idx++;
-
-   /* Load the hash current length */
-   hw_desc_init(&desc[idx]);
-   set_cipher_mode(&desc[idx], ctx->hw_mode);
-   set_din_sram(&desc[idx],
-cc_

[PATCH v3 20/27] staging: ccree: fix indentation of func params

[Gilad Ben-Yossef]

Fix indentation of some function params in hash code for
better readability.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_hash.c | 46 +---
 1 file changed, 20 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index 1cc3fae..c04b335 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -109,8 +109,7 @@ static int cc_map_result(struct device *dev, struct 
ahash_req_ctx *state,
 {
state->digest_result_dma_addr =
dma_map_single(dev, state->digest_result_buff,
-  digestsize,
-  DMA_BIDIRECTIONAL);
+  digestsize, DMA_BIDIRECTIONAL);
if (dma_mapping_error(dev, state->digest_result_dma_addr)) {
dev_err(dev, "Mapping digest result buffer %u B for DMA 
failed\n",
digestsize);
@@ -264,16 +263,12 @@ static void cc_unmap_result(struct device *dev, struct 
ahash_req_ctx *state,
unsigned int digestsize, u8 *result)
 {
if (state->digest_result_dma_addr) {
-   dma_unmap_single(dev,
-state->digest_result_dma_addr,
-digestsize,
- DMA_BIDIRECTIONAL);
+   dma_unmap_single(dev, state->digest_result_dma_addr, digestsize,
+DMA_BIDIRECTIONAL);
dev_dbg(dev, "unmpa digest result buffer va (%pK) pa (%pad) len 
%u\n",
state->digest_result_buff,
&state->digest_result_dma_addr, digestsize);
-   memcpy(result,
-  state->digest_result_buff,
-  digestsize);
+   memcpy(result, state->digest_result_buff, digestsize);
}
state->digest_result_dma_addr = 0;
 }
@@ -1100,25 +1095,25 @@ static int cc_xcbc_setkey(struct crypto_ahash *ahash,
hw_desc_init(&desc[idx]);
set_din_const(&desc[idx], 0x01010101, CC_AES_128_BIT_KEY_SIZE);
set_flow_mode(&desc[idx], DIN_AES_DOUT);
-   set_dout_dlli(&desc[idx], (ctx->opad_tmp_keys_dma_addr +
-  XCBC_MAC_K1_OFFSET),
- CC_AES_128_BIT_KEY_SIZE, NS_BIT, 0);
+   set_dout_dlli(&desc[idx],
+ (ctx->opad_tmp_keys_dma_addr + XCBC_MAC_K1_OFFSET),
+ CC_AES_128_BIT_KEY_SIZE, NS_BIT, 0);
idx++;
 
hw_desc_init(&desc[idx]);
set_din_const(&desc[idx], 0x02020202, CC_AES_128_BIT_KEY_SIZE);
set_flow_mode(&desc[idx], DIN_AES_DOUT);
-   set_dout_dlli(&desc[idx], (ctx->opad_tmp_keys_dma_addr +
-  XCBC_MAC_K2_OFFSET),
- CC_AES_128_BIT_KEY_SIZE, NS_BIT, 0);
+   set_dout_dlli(&desc[idx],
+ (ctx->opad_tmp_keys_dma_addr + XCBC_MAC_K2_OFFSET),
+ CC_AES_128_BIT_KEY_SIZE, NS_BIT, 0);
idx++;
 
hw_desc_init(&desc[idx]);
set_din_const(&desc[idx], 0x03030303, CC_AES_128_BIT_KEY_SIZE);
set_flow_mode(&desc[idx], DIN_AES_DOUT);
-   set_dout_dlli(&desc[idx], (ctx->opad_tmp_keys_dma_addr +
-  XCBC_MAC_K3_OFFSET),
-  CC_AES_128_BIT_KEY_SIZE, NS_BIT, 0);
+   set_dout_dlli(&desc[idx],
+ (ctx->opad_tmp_keys_dma_addr + XCBC_MAC_K3_OFFSET),
+ CC_AES_128_BIT_KEY_SIZE, NS_BIT, 0);
idx++;
 
rc = cc_send_sync_request(ctx->drvdata, &cc_req, desc, idx);
@@ -1245,8 +1240,7 @@ static int cc_cra_init(struct crypto_tfm *tfm)
struct ahash_alg *ahash_alg =
container_of(hash_alg_common, struct ahash_alg, halg);
struct cc_hash_alg *cc_alg =
-   container_of(ahash_alg, struct cc_hash_alg,
-ahash_alg);
+   container_of(ahash_alg, struct cc_hash_alg, ahash_alg);
 
crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
 sizeof(struct ahash_req_ctx));
@@ -1391,8 +1385,8 @@ static int cc_mac_final(struct ahash_request *req)
set_cipher_mode(&desc[idx], DRV_CIPHER_ECB);
set_cipher_config0(&desc[idx], DRV_CRYPTO_DIRECTION_DECRYPT);
set_din_type(&desc[idx], DMA_DLLI,
-(ctx->opad_tmp_keys_dma_addr +
- XCBC_MAC_K1_OFFSET), key_size, NS_BIT);
+(ctx->opad_tmp_keys_dma_addr + XCBC_MAC_K1_OFFSET),
+key_size, NS_BIT);
set_key_size_aes(&desc[idx], key_len);
set_flow_mode(&desc[idx], S_DIN_to_AES);
set_setup_mode(&desc[idx], SETUP_LOAD_KEY0);
@@ -2197,8 +2191,8 @@ static v

[PATCH v3 19/27] staging: ccree: do not map bufs in ahash_init

[Gilad Ben-Yossef]

hash_init was mapping DMA memory that were then being unmap in
hash_digest/final/finup callbacks, which is against the Crypto API
usage rules (see discussion at
https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg30077.html)

Fix it by moving all buffer mapping/unmapping or each Crypto API op.

This also properly deals with hash_import() not knowing if
hash_init was called or not as it now no longer matters.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_hash.c | 192 +--
 1 file changed, 103 insertions(+), 89 deletions(-)

diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index b557db2..1cc3fae 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -123,34 +123,20 @@ static int cc_map_result(struct device *dev, struct 
ahash_req_ctx *state,
return 0;
 }
 
-static int cc_map_req(struct device *dev, struct ahash_req_ctx *state,
- struct cc_hash_ctx *ctx, gfp_t flags)
+static void cc_init_req(struct device *dev, struct ahash_req_ctx *state,
+   struct cc_hash_ctx *ctx)
 {
bool is_hmac = ctx->is_hmac;
-   int rc = -ENOMEM;
 
memset(state, 0, sizeof(*state));
 
-   state->digest_buff_dma_addr =
-   dma_map_single(dev, state->digest_buff,
-  ctx->inter_digestsize, DMA_BIDIRECTIONAL);
-   if (dma_mapping_error(dev, state->digest_buff_dma_addr)) {
-   dev_err(dev, "Mapping digest len %d B at va=%pK for DMA 
failed\n",
-   ctx->inter_digestsize, state->digest_buff);
-   goto fail0;
-   }
-   dev_dbg(dev, "Mapped digest %d B at va=%pK to dma=%pad\n",
-   ctx->inter_digestsize, state->digest_buff,
-   &state->digest_buff_dma_addr);
-
if (is_hmac) {
-   dma_sync_single_for_cpu(dev, ctx->digest_buff_dma_addr,
-   ctx->inter_digestsize,
-   DMA_BIDIRECTIONAL);
-   if (ctx->hw_mode == DRV_CIPHER_XCBC_MAC ||
-   ctx->hw_mode == DRV_CIPHER_CMAC) {
-   memset(state->digest_buff, 0, ctx->inter_digestsize);
-   } else { /*sha*/
+   if (ctx->hw_mode != DRV_CIPHER_XCBC_MAC &&
+   ctx->hw_mode != DRV_CIPHER_CMAC) {
+   dma_sync_single_for_cpu(dev, ctx->digest_buff_dma_addr,
+   ctx->inter_digestsize,
+   DMA_BIDIRECTIONAL);
+
memcpy(state->digest_buff, ctx->digest_buff,
   ctx->inter_digestsize);
 #if (CC_DEV_SHA_MAX > 256)
@@ -181,9 +167,24 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
 
memcpy(state->digest_buff, larval, ctx->inter_digestsize);
}
+}
 
-   dma_sync_single_for_device(dev, state->digest_buff_dma_addr,
-  ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+static int cc_map_req(struct device *dev, struct ahash_req_ctx *state,
+ struct cc_hash_ctx *ctx)
+{
+   bool is_hmac = ctx->is_hmac;
+
+   state->digest_buff_dma_addr =
+   dma_map_single(dev, state->digest_buff,
+  ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+   if (dma_mapping_error(dev, state->digest_buff_dma_addr)) {
+   dev_err(dev, "Mapping digest len %d B at va=%pK for DMA 
failed\n",
+   ctx->inter_digestsize, state->digest_buff);
+   return -EINVAL;
+   }
+   dev_dbg(dev, "Mapped digest %d B at va=%pK to dma=%pad\n",
+   ctx->inter_digestsize, state->digest_buff,
+   &state->digest_buff_dma_addr);
 
if (ctx->hw_mode != DRV_CIPHER_XCBC_MAC) {
state->digest_bytes_len_dma_addr =
@@ -192,13 +193,11 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
if (dma_mapping_error(dev, state->digest_bytes_len_dma_addr)) {
dev_err(dev, "Mapping digest len %u B at va=%pK for DMA 
failed\n",
HASH_LEN_SIZE, state->digest_bytes_len);
-   goto fail4;
+   goto unmap_digest_buf;
}
dev_dbg(dev, "Mapped digest len %u B at va=%pK to dma=%pad\n",
HASH_LEN_SIZE, state->digest_bytes_len,
&state->digest_bytes_len_dma_addr);
-   } else {
-   state->digest_bytes_len_dma_addr = 0;
}
 
if (is_hmac && ctx->hash_mode != DRV_HASH_NULL) {
@@ -210,35 +209,29 @@ static int cc_map_req(struct device *dev, struct 
ahash_req_ctx *state,
dev_err(dev, "Mapping opad digest %d B at va=%pK for 
DMA failed\n",
   

[PATCH v3 22/27] staging: ccree: put pointer next to var name

[Gilad Ben-Yossef]

Put pointer next to var name as per coding style.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_request_mgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
b/drivers/staging/ccree/ssi_request_mgr.c
index 78f25e5..dc3be29 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -166,7 +166,7 @@ static void enqueue_seq(struct cc_drvdata *drvdata, struct 
cc_hw_desc seq[],
unsigned int seq_len)
 {
int i, w;
-   void * __iomem reg = drvdata->cc_base + CC_REG(DSCRPTR_QUEUE_WORD0);
+   void __iomem *reg = drvdata->cc_base + CC_REG(DSCRPTR_QUEUE_WORD0);
struct device *dev = drvdata_to_dev(drvdata);
 
/*
-- 
2.7.4

[PATCH v3 23/27] stating: ccree: fix allocation of void sized buf

[Gilad Ben-Yossef]

We were allocating buffers using sizeof(*struct->field) where field was
type void.  Fix it by having a local variable with the real type.

Cc: sta...@vger.kernel.org
Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_ivgen.c| 9 -
 drivers/staging/ccree/ssi_sram_mgr.c | 9 ++---
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/ccree/ssi_ivgen.c 
b/drivers/staging/ccree/ssi_ivgen.c
index 6b92649..2ba15a5 100644
--- a/drivers/staging/ccree/ssi_ivgen.c
+++ b/drivers/staging/ccree/ssi_ivgen.c
@@ -175,13 +175,10 @@ int cc_ivgen_init(struct cc_drvdata *drvdata)
int rc;
 
/* Allocate "this" context */
-   drvdata->ivgen_handle = kzalloc(sizeof(*drvdata->ivgen_handle),
-   GFP_KERNEL);
-   if (!drvdata->ivgen_handle)
+   ivgen_ctx = kzalloc(sizeof(*ivgen_ctx), GFP_KERNEL);
+   if (!ivgen_ctx)
return -ENOMEM;
 
-   ivgen_ctx = drvdata->ivgen_handle;
-
/* Allocate pool's header for initial enc. key/IV */
ivgen_ctx->pool_meta = dma_alloc_coherent(device, CC_IVPOOL_META_SIZE,
  &ivgen_ctx->pool_meta_dma,
@@ -200,6 +197,8 @@ int cc_ivgen_init(struct cc_drvdata *drvdata)
goto out;
}
 
+   drvdata->ivgen_handle = ivgen_ctx;
+
return cc_init_iv_sram(drvdata);
 
 out:
diff --git a/drivers/staging/ccree/ssi_sram_mgr.c 
b/drivers/staging/ccree/ssi_sram_mgr.c
index 1a2a7f4d..c5497aa 100644
--- a/drivers/staging/ccree/ssi_sram_mgr.c
+++ b/drivers/staging/ccree/ssi_sram_mgr.c
@@ -32,13 +32,16 @@ void cc_sram_mgr_fini(struct cc_drvdata *drvdata)
  */
 int cc_sram_mgr_init(struct cc_drvdata *drvdata)
 {
+   struct cc_sram_ctx *ctx;
+
/* Allocate "this" context */
-   drvdata->sram_mgr_handle = kzalloc(sizeof(*drvdata->sram_mgr_handle),
-  GFP_KERNEL);
+   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
 
-   if (!drvdata->sram_mgr_handle)
+   if (!ctx)
return -ENOMEM;
 
+   drvdata->sram_mgr_handle = ctx;
+
return 0;
 }
 
-- 
2.7.4

[PATCH v3 26/27] staging: ccree: update TODO

[Gilad Ben-Yossef]

Update TODO to reflect work done

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/TODO | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/TODO b/drivers/staging/ccree/TODO
index 6d8702b..b8e163d 100644
--- a/drivers/staging/ccree/TODO
+++ b/drivers/staging/ccree/TODO
@@ -6,5 +6,5 @@
 *  *
 *
 
-1. Handle HW FIFO fullness more cleanly.
+1. ???
 
-- 
2.7.4

[PATCH v3 25/27] staging: ccree: remove unneeded includes

[Gilad Ben-Yossef]

Remove include files not needed for compilation.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/cc_aead.c|  7 ---
 drivers/staging/ccree/cc_buffer_mgr.c  |  6 --
 drivers/staging/ccree/cc_cipher.c  |  4 
 drivers/staging/ccree/cc_driver.c  | 31 ---
 drivers/staging/ccree/cc_hash.c|  2 --
 drivers/staging/ccree/cc_ivgen.c   |  1 -
 drivers/staging/ccree/cc_pm.c  |  2 --
 drivers/staging/ccree/cc_request_mgr.c |  5 -
 8 files changed, 58 deletions(-)

diff --git a/drivers/staging/ccree/cc_aead.c b/drivers/staging/ccree/cc_aead.c
index da74423..265adff 100644
--- a/drivers/staging/ccree/cc_aead.c
+++ b/drivers/staging/ccree/cc_aead.c
@@ -3,18 +3,11 @@
 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include "cc_driver.h"
 #include "cc_buffer_mgr.h"
 #include "cc_aead.h"
diff --git a/drivers/staging/ccree/cc_buffer_mgr.c 
b/drivers/staging/ccree/cc_buffer_mgr.c
index 01c786c..14b2eab 100644
--- a/drivers/staging/ccree/cc_buffer_mgr.c
+++ b/drivers/staging/ccree/cc_buffer_mgr.c
@@ -1,17 +1,11 @@
 // SPDX-License-Identifier: GPL-2.0
 /* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
 
-#include 
-#include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
 
 #include "cc_buffer_mgr.h"
 #include "cc_lli_defs.h"
diff --git a/drivers/staging/ccree/cc_cipher.c 
b/drivers/staging/ccree/cc_cipher.c
index eca0578..8afdbc1 100644
--- a/drivers/staging/ccree/cc_cipher.c
+++ b/drivers/staging/ccree/cc_cipher.c
@@ -3,12 +3,8 @@
 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/staging/ccree/cc_driver.c 
b/drivers/staging/ccree/cc_driver.c
index 98d491e..b49bc25 100644
--- a/drivers/staging/ccree/cc_driver.c
+++ b/drivers/staging/ccree/cc_driver.c
@@ -5,43 +5,12 @@
 #include 
 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
-#include 
-
-/* cache.h required for L1_CACHE_ALIGN() and cache_line_size() */
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/staging/ccree/cc_hash.c b/drivers/staging/ccree/cc_hash.c
index 7c1645d..86f9ec7 100644
--- a/drivers/staging/ccree/cc_hash.c
+++ b/drivers/staging/ccree/cc_hash.c
@@ -3,10 +3,8 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/staging/ccree/cc_ivgen.c b/drivers/staging/ccree/cc_ivgen.c
index 43f70d4..25a3131 100644
--- a/drivers/staging/ccree/cc_ivgen.c
+++ b/drivers/staging/ccree/cc_ivgen.c
@@ -1,7 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
 
-#include 
 #include 
 #include "cc_driver.h"
 #include "cc_ivgen.h"
diff --git a/drivers/staging/ccree/cc_pm.c b/drivers/staging/ccree/cc_pm.c
index 1f5da86..c7d6b86 100644
--- a/drivers/staging/ccree/cc_pm.c
+++ b/drivers/staging/ccree/cc_pm.c
@@ -2,9 +2,7 @@
 /* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include "cc_driver.h"
 #include "cc_buffer_mgr.h"
diff --git a/drivers/staging/ccree/cc_request_mgr.c 
b/drivers/staging/ccree/cc_request_mgr.c
index cbcfcc3..8372410 100644
--- a/drivers/staging/ccree/cc_request_mgr.c
+++ b/drivers/staging/ccree/cc_request_mgr.c
@@ -2,11 +2,6 @@
 /* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include "cc_driver.h"
 #include "cc_buffer_mgr.h"
 #include "cc_request_mgr.h"
-- 
2.7.4

[PATCH v3 27/27] staging: ccree: add missing include

[Gilad Ben-Yossef]

Add the missing include of include file with function declarations.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/cc_debugfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/ccree/cc_debugfs.c 
b/drivers/staging/ccree/cc_debugfs.c
index f927a73..08f8db4 100644
--- a/drivers/staging/ccree/cc_debugfs.c
+++ b/drivers/staging/ccree/cc_debugfs.c
@@ -6,6 +6,7 @@
 #include 
 #include "cc_driver.h"
 #include "cc_crypto_ctx.h"
+#include "cc_debugfs.h"
 
 struct cc_debugfs_ctx {
struct dentry *dir;
-- 
2.7.4

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

[David Woodhouse]

On Sun, 2018-01-07 at 12:46 +0100, Borislav Petkov wrote:
> 
> > 
> > The other fun one for alternatives is in entry_64.S, where we really
> > need the return address of the call instruction to be *precisely* the 
> > .Lentry_SYSCALL_64_after_fastpath_call label, so we have to eschew the
> > normal NOSPEC_CALL there:
> 
> So CALL, as the doc says, pushes the offset of the *next* insn onto the
> stack and branches to the target address.
> 
> So I'm thinking, as long as the next insn doesn't move and gcc doesn't
> pad anything, you're fine.
> 
> However, I suspect that I'm missing something else here and I guess I'll
> have more clue if I look at the whole thing. So can you point me to your
> current branch so that I can take a look at the code?

http://git.infradead.org/users/dwmw2/linux-retpoline.git

In particular, this call site in entry_64.S:
http://git.infradead.org/users/dwmw2/linux-retpoline.git/blob/0f5c54a36e:/arch/x86/entry/entry_64.S#l270

It's still just unconditionally calling the out-of-line thunk and not
using ALTERNATIVE in the CONFIG_RETPOLINE case. I can't just use the
NOSPEC_CALL macro from
http://git.infradead.org/users/dwmw2/linux-retpoline.git/blob/0f5c54a36e:/arch/x86/include/asm/nospec-branch.h#l46
because of that requirement that the return address (on the stack) for
the CALL instruction must be precisely at the end, in all cases.

Each of the three alternatives *does* end with the CALL, it's just that
for the two which are shorter than the full retpoline one, they'll get
padded with NOPs at the end, so the return address on the stack *won't*
be what's expected.

Explicitly padding the alternatives with leading NOPs so that they are
all precisely the same length would work, and if the alternatives
mechanism were to pad the shorter ones with leading NOPs instead of
trailing NOPs that would *also* work (but be fairly difficult
especially to do that for oldinstr).

I'm not sure I *see* a simple answer, and it isn't really that bad to
just do what GCC is doing and unconditionally call the out-of-line
thunk. So feel free to just throw your hands up in horror and say "no,
we can't cope with that" :)

smime.p7s
Description: S/MIME cryptographic signature

Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs

[Theodore Ts'o]

On Sun, Jan 07, 2018 at 11:16:28AM +0200, Avi Kivity wrote:
> I think capabilities will work just as well with cgroups. The container
> manager will set CAP_PAYLOAD to payload containers; and if those run an init
> system or a container manager themselves, they'll drop CAP_PAYLOAD for all
> process/sub-containers but their payloads.

The reason why cgroups are better is Spectre can be used to steal
information from within the same privilege level --- e.g., you could
use Javascript to steal a user's Coindesk credentials or Lastpass
data, which is going to be *way* more lucrative than trying to mine
cryptocurrency in the sly in a user's browser.  :-)

As a result, you probably want Spectre mitigations to be enabled in a
root process --- which means capabilities aren't the right answer.

Regards,

- Ted

Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs

[Ozgur]

07.01.2018, 15:29, "Theodore Ts'o" :
> On Sun, Jan 07, 2018 at 11:16:28AM +0200, Avi Kivity wrote:
>>  I think capabilities will work just as well with cgroups. The container
>>  manager will set CAP_PAYLOAD to payload containers; and if those run an init
>>  system or a container manager themselves, they'll drop CAP_PAYLOAD for all
>>  process/sub-containers but their payloads.
>
> The reason why cgroups are better is Spectre can be used to steal
> information from within the same privilege level --- e.g., you could
> use Javascript to steal a user's Coindesk credentials or Lastpass
> data, which is going to be *way* more lucrative than trying to mine
> cryptocurrency in the sly in a user's browser. :-)

I think the web coin mining pages also work with this method they probably use 
JS in the background but currently, impossible to do kernel-level operations.
All process start on the browser level and Spectre not read kernel memory, 
right?

Ozgur

> As a result, you probably want Spectre mitigations to be enabled in a
> root process --- which means capabilities aren't the right answer.
>
> Regards,
>
> - Ted

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

[Mike Galbraith]

On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote:
> On Sun 07-01-18 10:11:15, Greg KH wrote:
> > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote:
> > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote:
> > > > 4.14-stable review patch.  If anyone has any objections, please let me 
> > > > know.
> > > 
> > > FYI, this broke kdump, or rather the makedumpfile part thereof.
> > >  Forward looking wreckage is par for the kdump course, but...
> > 
> > Is it also broken in Linus's tree with this patch?  Or is there an
> > add-on patch that I should apply to 4.14 to resolve this issue there?
> 
> This one 
> http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com
> I guess.

That won't unbreak kdump, else master wouldn't be broken.  I don't care
deeply, or know if anyone else does, I'm just reporting it because I
met it and chased it down.

-Mike

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

[Krzysztof Kozlowski]

On Fri, Dec 22, 2017 at 1:05 PM, Jeff Layton  wrote:
> From: Jeff Layton 
>
> Since i_version is mostly treated as an opaque value, we can exploit that
> fact to avoid incrementing it when no one is watching. With that change,
> we can avoid incrementing the counter on writes, unless someone has
> queried for it since it was last incremented. If the a/c/mtime don't
> change, and the i_version hasn't changed, then there's no need to dirty
> the inode metadata on a write.
>
> Convert the i_version counter to an atomic64_t, and use the lowest order
> bit to hold a flag that will tell whether anyone has queried the value
> since it was last incremented.
>
> When we go to maybe increment it, we fetch the value and check the flag
> bit.  If it's clear then we don't need to do anything if the update
> isn't being forced.
>
> If we do need to update, then we increment the counter by 2, and clear
> the flag bit, and then use a CAS op to swap it into place. If that
> works, we return true. If it doesn't then do it again with the value
> that we fetch from the CAS operation.
>
> On the query side, if the flag is already set, then we just shift the
> value down by 1 bit and return it. Otherwise, we set the flag in our
> on-stack value and again use cmpxchg to swap it into place if it hasn't
> changed. If it has, then we use the value from the cmpxchg as the new
> "old" value and try again.
>
> This method allows us to avoid incrementing the counter on writes (and
> dirtying the metadata) under typical workloads. We only need to increment
> if it has been queried since it was last changed.
>
> Signed-off-by: Jeff Layton 
> ---
>  include/linux/fs.h   |   2 +-
>  include/linux/iversion.h | 208 
> ++-
>  2 files changed, 154 insertions(+), 56 deletions(-)
>

Hi,

On recent linux-next my ARM/Exynos boards fail to boot over nfsroot.
This commit popped up through bisect (log at the end). Systemd
timeouts on some device-specific services, including mounting ext4
/home:

[ *** ] (1 of 4) A start job is running for…ress polling (1min 41s / no limit)
[ TIME ] Timed out waiting for device dev-ttySAC2.device.
Jan 07 13:29:38 [DEPEND] Dependency failed for Serial Getty on ttySAC2.
Jan 07 13:29:38 [ TIME ] Timed out waiting for device
dev-disk-by\x2dlabel-home.device.
Jan 07 13:29:38 [DEPEND] Dependency failed for /home.
Jan 07 13:29:38 [DEPEND] Dependency failed for Local File Systems.
Jan 07 13:29:38 [DEPEND] Dependency failed for File System Check on
/dev/disk/by-label/home.
Jan 07 13:30:02 [ *** ] (1 of 2) A start job is running for…ress
polling (1min 53s / no limit)

Kernel command line:
console=tty1 console=ttySAC2,115200n8
ip=192.168.1.11:192.168.1.10:192.168.1.1:255.255.255.0::eth0:none
nfsrootdebug root=/dev/nfs
nfsroot=192.168.1.10:/srv/nfs/odroidxu3,vers=4,nolock rootwait rw
smsc95xx.macaddr=00:1e:06:61:7a:93 no_console_suspend

/home is /dev/mmcblk1p2:
kozik@odroidxu3:~$ tune2fs -l /dev/mmcblk1p2
tune2fs 1.43.7 (16-Oct-2017)
Filesystem volume name:   home
Last mounted on:  /home
Filesystem UUID:  3f9dbeba-2738-45d3-807e-c1b2e21128ed
Filesystem magic number:  0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features:  has_journal ext_attr resize_inode dir_index
filetype needs_recovery extent flex_bg sparse_super large_file
uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options:user_xattr acl
Filesystem state: clean
Errors behavior:  Continue
Filesystem OS type:   Linux
Inode count:  1430800
Block count:  5717760
Reserved block count: 285888
Free blocks:  5467576
Free inodes:  1428301
First block:  0
Block size:   4096
Fragment size:4096
Reserved GDT blocks:  1022
Blocks per group: 32768
Fragments per group:  32768
Inodes per group: 8176
Inode blocks per group:   511
Flex block group size:16
Filesystem created:   Thu May 21 12:17:05 2015
Last mount time:  Thu Dec 21 13:31:26 2017
Last write time:  Thu Dec 21 13:31:26 2017
Mount count:  1
Maximum mount count:  -1
Last checked: Thu Dec 21 13:31:25 2017
Check interval:   0 ()
Lifetime writes:  126 GB
Reserved blocks uid:  0 (user root)
Reserved blocks gid:  0 (group root)
First inode:  11
Inode size:   256
Required extra isize: 28
Desired extra isize:  28
Journal inode:8
Default directory hash:   half_md4
Directory Hash Seed:  42e17e23-86b2-4356-ad63-78aa51651d03
Journal backup:   inode blocks


Full dmesg log:
http://www.krzk.eu/#/builders/1/builds/1258/steps/10/logs/serial0

The regular boot from rootfs on SD card also fails - but without any
serial console logs (just "Starting kernel...") so the real cause is
unknown.

Any hints?

Best regards,
Krzysztof


bisect log:
# bad: [73005e1a35fd67c64

Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs

[Avi Kivity]

On 01/07/2018 02:29 PM, Theodore Ts'o wrote:

On Sun, Jan 07, 2018 at 11:16:28AM +0200, Avi Kivity wrote:

I think capabilities will work just as well with cgroups. The container
manager will set CAP_PAYLOAD to payload containers; and if those run an init
system or a container manager themselves, they'll drop CAP_PAYLOAD for all
process/sub-containers but their payloads.

The reason why cgroups are better is Spectre can be used to steal
information from within the same privilege level --- e.g., you could
use Javascript to steal a user's Coindesk credentials or Lastpass
data, which is going to be *way* more lucrative than trying to mine
cryptocurrency in the sly in a user's browser.  :-)

As a result, you probably want Spectre mitigations to be enabled in a
root process --- which means capabilities aren't the right answer.




I don't see the connection. The browser wouldn't run with CAP_PAYLOAD set.

In a desktop system, only init retains CAP_PAYLOAD.

On a server that runs one application (and some supporting processes), 
only init and that one application have CAP_PAYLOAD (if the sysadmin 
makes it so).


On a containerized server that happens to run just one application, init 
will retain CAP_PAYLOAD, as well as the process in the container (if the 
sysadmin makes it so).


On a containerized server that happens to run just one application, 
which itself runs an init system, the two inits will retain CAP_PAYLOAD, 
as well as the application process (if the sysadmin makes it so).

Re: [alsa-devel][PATCH v7] ASoC: TSCS42xx: Add support for Tempo Semiconductor's TSCS42xx audio CODEC

[Steven Eckhoff]

On Fri, Jan 05, 2018 at 12:38:03PM +, Mark Brown wrote:
> This doesn't apply cleanly against current code, what did you submit
> against?  :(  These aren't trivial things that have just been added to
> my tree in this development cycle either, it looks like you're
> submitting against some older kernel.  I've applied anyway but please be
> careful.
I apologize for this. I created the patch against the master branch and
did not notice that is was las updated 5 years ago. On IRC I was told to
use for-next. I will use that tree to create the next patch against.

Re: [RFCv2 2/4] Documentation: document nospec helpers

[Mark Rutland]

On Sat, Jan 06, 2018 at 09:20:59PM -0800, Randy Dunlap wrote:
> On 01/05/18 06:57, Mark Rutland wrote:
> > Document the rationale and usage of the new nospec*() helpers.
> > 
> > Signed-off-by: Mark Rutland 
> > Signed-off-by: Will Deacon 
> > Cc: Dan Williams 
> > Cc: Jonathan Corbet 
> > Cc: Peter Zijlstra 
> > ---
> >  Documentation/speculation.txt | 166 
> > ++
> >  1 file changed, 166 insertions(+)
> >  create mode 100644 Documentation/speculation.txt
> > 
> > diff --git a/Documentation/speculation.txt b/Documentation/speculation.txt
> > new file mode 100644
> > index ..748fcd4dcda4
> > --- /dev/null
> > +++ b/Documentation/speculation.txt
> > @@ -0,0 +1,166 @@
> > +
> > +Typically speculative execution cannot be observed from architectural 
> > state,
> > +such as the contents of registers. However, in some cases it is possible to
> > +observe its impact on microarchitectural state, such as the presence or
> > +absence of data in caches. Such state may form side-channels which can be
> > +observed to extract secret information.
> 
> I'm curious about what it takes to observe this...
> 
> or is that covered in the exploit papers?

That's covered elsewhere, e.g.

https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

I'll add some references.

Thanks,
Mark.

[GIT PULL] LED fix for 4.15-rc7

[Jacek Anaszewski]

Hi Linus,

Please pull LED regression fix for 4.15-rc7.

The commit 2b83ff96f51d for 4.15-rc6, which was fixing LED brightness
setting after clearing delay_off broke the behavior on any alteration
of delay_on{off} properties, due to use of a LED core helper that does
too much for this particular case.

The following changes since commit 30a7acd573899fd8b8ac39236eff6468b195ac7d:

  Linux 4.15-rc6 (2017-12-31 14:47:43 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git 
tags/led_fixes_for_4.15-rc7

for you to fetch changes up to 7b6af2c53192f1766892ef40c8f48a413509ed72:

  leds: core: Fix regression caused by commit 2b83ff96f51d (2018-01-07 13:27:07 
+0100)

Thanks,
Jacek Anaszewski


LED fix for 4.15-rc7

Jacek Anaszewski (1):
  leds: core: Fix regression caused by commit 2b83ff96f51d

 drivers/leds/led-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Re: [PATCH] i2c: core: report OF style module alias for devices registered via OF

[Javier Martinez Canillas]

Hello Wolfram,

On Sun, Dec 3, 2017 at 10:40 PM, Javier Martinez Canillas
 wrote:
> The buses should honor the firmware interface used to register the device,
> but the I2C core reports a MODALIAS of the form i2c: even for I2C
> devices registered via OF.
>
> This means that user-space will never get an OF stype uevent MODALIAS even
> when the drivers modules contain aliases exported from both the I2C and OF
> device ID tables. For example, an Atmel maXTouch Touchscreen registered by
> a DT node with compatible "atmel,maxtouch" has the following module alias:
>
> $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
> i2c:maxtouch
>
> So udev won't be able to auto-load a module for an OF-only device driver.
> Many OF-only drivers duplicate the OF device ID table entries in an I2C ID
> table only has a workaround for how the I2C core reports the module alias.
>
> This patch changes the I2C core to report an OF related MODALIAS uevent if
> the device was registered via OF. So for the previous example, after this
> patch, the reported MODALIAS for the Atmel maXTouch will be the following:
>
> $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
> of:NtrackpadTCatmel,maxtouch
>
> NOTE: This patch may break out-of-tree drivers that were relying on this
>   behavior, and only had an I2C device ID table even when the device
>   was registered via OF. There are no remaining drivers in mainline
>   that do this, but out-of-tree drivers have to be fixed and define
>   a proper OF device ID table to have module auto-loading working.
>
> Signed-off-by: Javier Martinez Canillas 
> ---

Any comments on this patch?

Best regards,
Javier

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

[Knut Omang]

On Sun, 2018-01-07 at 13:03 +0100, Philippe Ombredanne wrote:
> Knut,
> 
> On Fri, Jan 5, 2018 at 3:30 PM, Jani Nikula  
> wrote:
> > On Thu, 04 Jan 2018, Knut Omang  wrote:
> >> On Thu, 2018-01-04 at 17:50 +0200, Jani Nikula wrote:
> >>> On Thu, 04 Jan 2018, Knut Omang  wrote:
> >>> > Add scripts/runchecks which has generic support for running
> >>> > checker tools in a convenient and user friendly way that
> >>> > the author hopes can contribute to rein in issues detected
> >>> > by these tools in a manageable and convenient way.
> 
> 
> 
> >>> > --- /dev/null
> >>> > +++ b/scripts/runchecks
> >>> > @@ -0,0 +1,734 @@
> >>> > +#!/usr/bin/python
> >>> > +
> >>> > +# SPDX-License-Identifier: GPL-2.0
> 
> Thank you for using an SPDX tag here   .
> 
> 
> 
> >>> > +#
> >>> > +# 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.
> >>> > +
> 
> but then please DRY: do not add this extra legalese which is redundant.

Ah, I see - just trying to be compliant in all dimensions
 - will fix,

Thanks,
Knut

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

[Michal Hocko]

On Sun 07-01-18 13:44:02, Mike Galbraith wrote:
> On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote:
> > On Sun 07-01-18 10:11:15, Greg KH wrote:
> > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote:
> > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote:
> > > > > 4.14-stable review patch.  If anyone has any objections, please let 
> > > > > me know.
> > > > 
> > > > FYI, this broke kdump, or rather the makedumpfile part thereof.
> > > >  Forward looking wreckage is par for the kdump course, but...
> > > 
> > > Is it also broken in Linus's tree with this patch?  Or is there an
> > > add-on patch that I should apply to 4.14 to resolve this issue there?
> > 
> > This one 
> > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com
> > I guess.
> 
> That won't unbreak kdump, else master wouldn't be broken.  I don't care
> deeply, or know if anyone else does, I'm just reporting it because I
> met it and chased it down.

OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation
for mem_section") made it in after rc6. I am still wondering why
83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for
CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first
place.
-- 
Michal Hocko
SUSE Labs

[PATCH v2 0/2] video-UDLFB: Adjustments for dlfb_realloc_framebuffer()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 7 Jan 2018 14:24:34 +0100

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Return an error code only as a constant
  Delete an error message for a failed memory allocation

---

v2:
Rebased on Linux next-20180105.

 drivers/video/fbdev/udlfb.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

-- 
2.15.1

[PATCH v2 1/2] video: udlfb: Return an error code only as a constant in dlfb_realloc_framebuffer()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 7 Jan 2018 14:02:36 +0100

* Return an error code without storing it in an intermediate variable.

* Delete the label "error" and local variable "retval"
  which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring 
---

v2:
This update suggestion was rebased on source files from the software
"Linux next-20180105".

 drivers/video/fbdev/udlfb.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 99ce445986b3..560a6b6044a5 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1157,7 +1157,6 @@ static struct fb_ops dlfb_ops = {
  */
 static int dlfb_realloc_framebuffer(struct dlfb_data *dev, struct fb_info 
*info)
 {
-   int retval = -ENOMEM;
int old_len = info->fix.smem_len;
int new_len;
unsigned char *old_fb = info->screen_base;
@@ -1175,7 +1174,7 @@ static int dlfb_realloc_framebuffer(struct dlfb_data 
*dev, struct fb_info *info)
new_fb = vmalloc(new_len);
if (!new_fb) {
pr_err("Virtual framebuffer alloc failed\n");
-   goto error;
+   return -ENOMEM;
}
 
if (info->screen_base) {
@@ -1203,11 +1202,7 @@ static int dlfb_realloc_framebuffer(struct dlfb_data 
*dev, struct fb_info *info)
dev->backing_buffer = new_back;
}
}
-
-   retval = 0;
-
-error:
-   return retval;
+   return 0;
 }
 
 /*
-- 
2.15.1

[PATCH v2 2/2] video: udlfb: Delete an error message for a failed memory allocation in dlfb_realloc_framebuffer()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 7 Jan 2018 14:07:36 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
This update suggestion was rebased on source files from the software
"Linux next-20180105" together with an other change combination.

 drivers/video/fbdev/udlfb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 560a6b6044a5..0c781b077aab 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1172,10 +1172,8 @@ static int dlfb_realloc_framebuffer(struct dlfb_data 
*dev, struct fb_info *info)
 * Alloc system memory for virtual framebuffer
 */
new_fb = vmalloc(new_len);
-   if (!new_fb) {
-   pr_err("Virtual framebuffer alloc failed\n");
+   if (!new_fb)
return -ENOMEM;
-   }
 
if (info->screen_base) {
memcpy(new_fb, old_fb, old_len);
-- 
2.15.1

[PATCH] Revert "ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells"

[Stefan Wahren]

This reverts commit 014d6da6cb2525d7f48fb08c705cb130cc7b5f4a.

The DT clean up could trigger an endless deferred probe of DWC2 USB driver
on the Raspberry Pi 2/3. So revert the change until we fixed the probing
issue.

Signed-off-by: Stefan Wahren 
---

Hi Arnd,
hi Olof,
i hope this has a chance to get into 4.15.

 arch/arm/boot/dts/bcm283x.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index dcde93c..013431e 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -639,6 +639,5 @@
 
usbphy: phy {
compatible = "usb-nop-xceiv";
-   #phy-cells = <0>;
};
 };
-- 
2.7.4

[PATCH] soc: imx: gpc: de-register power domains only if initialized

[Stefan Agner]

If power domain information are missing in the device tree, no
power domains get initialized. However, imx_gpc_remove tries to
remove power domains always in the old DT binding case. Only
remove power domains when imx_gpc_probe initialized them in
first place.

Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver")
Cc: Lucas Stach 
Signed-off-by: Stefan Agner 
---
 drivers/soc/imx/gpc.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index 53f7275d6cbd..62bb724726d9 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -470,13 +470,21 @@ static int imx_gpc_probe(struct platform_device *pdev)
 
 static int imx_gpc_remove(struct platform_device *pdev)
 {
+   struct device_node *pgc_node;
int ret;
 
+   pgc_node = of_get_child_by_name(pdev->dev.of_node, "pgc");
+
+   /* bail out if DT too old and doesn't provide the necessary info */
+   if (!of_property_read_bool(pdev->dev.of_node, "#power-domain-cells") &&
+   !pgc_node)
+   return 0;
+
/*
 * If the old DT binding is used the toplevel driver needs to
 * de-register the power domains
 */
-   if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
+   if (!pgc_node) {
of_genpd_del_provider(pdev->dev.of_node);
 
ret = pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
-- 
2.15.1

[GIT PULL] apparmor fix for 4.15-rc7

[John Johansen]

Linus,

can you please pull the following regression fix for apparmor.

It fixes a regression when the kernel feature set is reported as
supporting mount and policy is pinned to a feature set that does not
support mount mediation.


thanks
-- John



The following changes since commit 30a7acd573899fd8b8ac39236eff6468b195ac7d:

  Linux 4.15-rc6 (2017-12-31 14:47:43 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor 
tags/apparmor-pr-2018-01-07

for you to fetch changes up to 5b9f57cf47b87f07210875d6a24776b4496b818d:

  apparmor: fix regression in mount mediation when feature set is pinned 
(2018-01-05 15:07:42 -0800)


- fix regression in mount mediation when feature set is pinned


John Johansen (1):
  apparmor: fix regression in mount mediation when feature set is pinned

 security/apparmor/mount.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)