Re: [PATCH 01/18] arm64: consistently use unsigned long for thread flags

gt; quantity. > > For consistency, and to avoid problems if we end up with more than 32 > flags, let's make do_notify_resume take the flags as a 64-bit unsigned > long. Looks sensible. Reviewed-by: Dave Martin > > Signed-off-by: Mark Rutland > Cc: Catalin Marinas > Cc: Wil

[PATCH REPOST 2/5] ARM: Use update_thread_flag()

This patch uses the new update_thread_flag() helper to simplify an if () set; else clear; construct. No functional change. Signed-off-by: Dave Martin <dave.mar...@arm.com> Cc: Russell King <li...@armlinux.org.uk> --- arch/arm/kernel/elf.c | 9 +++-- 1 file changed, 3 inse

[PATCH REPOST 2/5] ARM: Use update_thread_flag()

This patch uses the new update_thread_flag() helper to simplify an if () set; else clear; construct. No functional change. Signed-off-by: Dave Martin Cc: Russell King --- arch/arm/kernel/elf.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/arm/kernel/elf.c b

[PATCH REPOST 4/5] powerpc: Use update_thread_flag()

This patch uses the new update_thread_flag() helper to simplify a couple of if () set; else clear; constructs. No functional change. Signed-off-by: Dave Martin <dave.mar...@arm.com> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> Cc: Paul Mackerras <pau...@samba.org> Cc

[PATCH REPOST 3/5] MIPS: Use update{,_tsk}_thread_flag()

This patch uses the new update_thread_flag() helpers to simplify a couple of if () set; else clear; constructs. No functional change. Signed-off-by: Dave Martin <dave.mar...@arm.com> Cc: Ralf Baechle <r...@linux-mips.org> Cc: James Hogan <jho...@kernel.org> --- arch/mips/ker

[PATCH REPOST 4/5] powerpc: Use update_thread_flag()

This patch uses the new update_thread_flag() helper to simplify a couple of if () set; else clear; constructs. No functional change. Signed-off-by: Dave Martin Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman --- arch/powerpc/include/asm/elf.h | 10 ++ 1 file

[PATCH REPOST 3/5] MIPS: Use update{,_tsk}_thread_flag()

This patch uses the new update_thread_flag() helpers to simplify a couple of if () set; else clear; constructs. No functional change. Signed-off-by: Dave Martin Cc: Ralf Baechle Cc: James Hogan --- arch/mips/kernel/elf.c | 10 ++ arch/mips/kernel/process.c | 15

[PATCH REPOST 1/5] thread_info: Port core code to use update_thread_flag() helpers

This patch ports a couple of relevant bits of the core kernel to use the new update_thread_flag() helpers. No functional change. Signed-off-by: Dave Martin <dave.mar...@arm.com> Cc: Ingo Molnar <mi...@redhat.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Steven Rostedt &l

[PATCH REPOST 1/5] thread_info: Port core code to use update_thread_flag() helpers

This patch ports a couple of relevant bits of the core kernel to use the new update_thread_flag() helpers. No functional change. Signed-off-by: Dave Martin Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Oleg Nesterov --- include/trace/syscall.h | 6 ++ kernel/ptrace.c

[PATCH REPOST 5/5] sparc: Use update_thread_flag()

This patch uses the new update_thread_flag() helper to simplify an if () set; else clear; construct. No functional change. Signed-off-by: Dave Martin <dave.mar...@arm.com> Cc: "David S. Miller" <da...@davemloft.net> --- arch/sparc/include/asm/elf_64.h | 5 + 1 fil

[PATCH REPOST 5/5] sparc: Use update_thread_flag()

This patch uses the new update_thread_flag() helper to simplify an if () set; else clear; construct. No functional change. Signed-off-by: Dave Martin Cc: "David S. Miller" --- arch/sparc/include/asm/elf_64.h | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/

[PATCH REPOST 0/5] Simplify setting thread flags to a particular value

/linux-arm-kernel/2018-May/576597.html Dave Martin (5): thread_info: Port core code to use update_thread_flag() helpers ARM: Use update_thread_flag() MIPS: Use update{,_tsk}_thread_flag() powerpc: Use update_thread_flag() sparc: Use update_thread_flag() arch/arm/kernel/elf.c | 9

[PATCH REPOST 0/5] Simplify setting thread flags to a particular value

/linux-arm-kernel/2018-May/576597.html Dave Martin (5): thread_info: Port core code to use update_thread_flag() helpers ARM: Use update_thread_flag() MIPS: Use update{,_tsk}_thread_flag() powerpc: Use update_thread_flag() sparc: Use update_thread_flag() arch/arm/kernel/elf.c | 9

[PATCH v7 00/16] KVM: arm64: Optimise FPSIMD context switching

/2018-May/thread.html Christoffer Dall (1): KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change Dave Martin (15): thread_info: Add update_thread_flag() helpers arm64: Use update{,_tsk}_thread_flag() KVM: arm64: Convert lazy FPSIMD context switch trap to C arm64: fpsimd: Generalise

[PATCH v7 00/16] KVM: arm64: Optimise FPSIMD context switching

/2018-May/thread.html Christoffer Dall (1): KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change Dave Martin (15): thread_info: Add update_thread_flag() helpers arm64: Use update{,_tsk}_thread_flag() KVM: arm64: Convert lazy FPSIMD context switch trap to C arm64: fpsimd: Generalise

[PATCH v6 00/15] KVM: arm64: Optimise FPSIMD context switching

] [RFC PATCH 0/6] Simplify setting thread flags to a particular value https://lkml.org/lkml/2018/4/19/225 [3] linux-arm-kernel archive http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/thread.html Christoffer Dall (1): KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change Dave

[PATCH v6 00/15] KVM: arm64: Optimise FPSIMD context switching

] [RFC PATCH 0/6] Simplify setting thread flags to a particular value https://lkml.org/lkml/2018/4/19/225 [3] linux-arm-kernel archive http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/thread.html Christoffer Dall (1): KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change Dave

[PATCH v5 01/14] thread_info: Add update_thread_flag() helpers

, cond) which do the equivalent of: if (cond) set*_thread_flag([...,] flag); else clear*_thread_flag([...,] flag); Signed-off-by: Dave Martin <dave.mar...@arm.com> Cc: Ingo Molnar <mi...@redhat.com> Cc: Peter Zijlstra <pet...@infradead.

[PATCH v5 00/14] KVM: arm64: Optimise FPSIMD context switching

kvm_arch_vcpu_run_pid_change Dave Martin (13): thread_info: Add update_thread_flag() helpers arm64: Use update{,_tsk}_thread_flag() KVM: arm64: Convert lazy FPSIMD context switch trap to C arm64: fpsimd: Generalise context saving for non-task contexts KVM: arm64: Optimise FPSIMD handling

[PATCH v5 01/14] thread_info: Add update_thread_flag() helpers

, cond) which do the equivalent of: if (cond) set*_thread_flag([...,] flag); else clear*_thread_flag([...,] flag); Signed-off-by: Dave Martin Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Oleg Nesterov --- include/linux/sched.h

[PATCH v5 00/14] KVM: arm64: Optimise FPSIMD context switching

kvm_arch_vcpu_run_pid_change Dave Martin (13): thread_info: Add update_thread_flag() helpers arm64: Use update{,_tsk}_thread_flag() KVM: arm64: Convert lazy FPSIMD context switch trap to C arm64: fpsimd: Generalise context saving for non-task contexts KVM: arm64: Optimise FPSIMD handling

Re: [PATCH] arm64: avoid potential infinity loop in dump_backtrace

On Fri, Apr 20, 2018 at 01:38:33PM +0800, Ji Zhang wrote: > When we dump the backtrace of some tasks there is a potential infinity > loop if the content of the stack changed, no matter the change is > because the task is running or other unexpected cases. > > This patch add stronger check on

Re: [PATCH] arm64: avoid potential infinity loop in dump_backtrace

On Fri, Apr 20, 2018 at 01:38:33PM +0800, Ji Zhang wrote: > When we dump the backtrace of some tasks there is a potential infinity > loop if the content of the stack changed, no matter the change is > because the task is running or other unexpected cases. > > This patch add stronger check on

[RFC PATCH 0/6] Simplify setting thread flags to a particular value

are in the first patch; other changes are split per-arch. Dave Martin (6): thread_info: Add update_thread_flag() helpers ARM: Use update_thread_flag() arm64: Use update{,_tsk}_thread_flag() MIPS: Use update{,_tsk}_thread_flag() powerpc: Use update_thread_flag() sparc: Use

[RFC PATCH 0/6] Simplify setting thread flags to a particular value

are in the first patch; other changes are split per-arch. Dave Martin (6): thread_info: Add update_thread_flag() helpers ARM: Use update_thread_flag() arm64: Use update{,_tsk}_thread_flag() MIPS: Use update{,_tsk}_thread_flag() powerpc: Use update_thread_flag() sparc: Use

[RFC PATCH 1/6] thread_info: Add update_thread_flag() helpers

, cond) which do the equivalent of: if (cond) set*_thread_flag([...,] flag); else clear*_thread_flag([...,] flag); Signed-off-by: Dave Martin <dave.mar...@arm.com> Cc: Ingo Molnar <mi...@redhat.com> Cc: Peter Zijlstra <pet...@infradead.

[RFC PATCH 1/6] thread_info: Add update_thread_flag() helpers

, cond) which do the equivalent of: if (cond) set*_thread_flag([...,] flag); else clear*_thread_flag([...,] flag); Signed-off-by: Dave Martin Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Oleg Nesterov --- Note, this patch assumes

[RFC PATCH 2/6] ARM: Use update_thread_flag()

This patch uses the new update_thread_flag() helper to simplify an if () set; else clear; construct. No functional change. Signed-off-by: Dave Martin <dave.mar...@arm.com> Cc: Russell King <li...@armlinux.org.uk> --- arch/arm/kernel/elf.c | 9 +++-- 1 file changed, 3 inse

[RFC PATCH 2/6] ARM: Use update_thread_flag()

This patch uses the new update_thread_flag() helper to simplify an if () set; else clear; construct. No functional change. Signed-off-by: Dave Martin Cc: Russell King --- arch/arm/kernel/elf.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/arm/kernel/elf.c b

[RFC PATCH 3/6] arm64: Use update{,_tsk}_thread_flag()

This patch uses the new update_thread_flag() helpers to simplify a couple of if () set; else clear; constructs. No functional change. Signed-off-by: Dave Martin <dave.mar...@arm.com> Cc: Catalin Marinas <catalin.mari...@arm.com> Cc: Will Deacon <will.dea...@arm.com> ---

[RFC PATCH 3/6] arm64: Use update{,_tsk}_thread_flag()

This patch uses the new update_thread_flag() helpers to simplify a couple of if () set; else clear; constructs. No functional change. Signed-off-by: Dave Martin Cc: Catalin Marinas Cc: Will Deacon --- arch/arm64/kernel/fpsimd.c | 19 +++ 1 file changed, 7 insertions(+), 12

[RFC PATCH 5/6] powerpc: Use update_thread_flag()

This patch uses the new update_thread_flag() helper to simplify a couple of if () set; else clear; constructs. No functional change. Signed-off-by: Dave Martin <dave.mar...@arm.com> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> Cc: Paul Mackerras <pau...@samba.org> Cc

[RFC PATCH 5/6] powerpc: Use update_thread_flag()

This patch uses the new update_thread_flag() helper to simplify a couple of if () set; else clear; constructs. No functional change. Signed-off-by: Dave Martin Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman --- arch/powerpc/include/asm/elf.h | 10 ++ 1 file

[RFC PATCH 4/6] MIPS: Use update{,_tsk}_thread_flag()

This patch uses the new update_thread_flag() helpers to simplify a couple of if () set; else clear; constructs. No functional change. Signed-off-by: Dave Martin <dave.mar...@arm.com> Cc: Ralf Baechle <r...@linux-mips.org> Cc: James Hogan <jho...@kernel.org> --- arch/mips/ker

[RFC PATCH 4/6] MIPS: Use update{,_tsk}_thread_flag()

This patch uses the new update_thread_flag() helpers to simplify a couple of if () set; else clear; constructs. No functional change. Signed-off-by: Dave Martin Cc: Ralf Baechle Cc: James Hogan --- arch/mips/kernel/elf.c | 10 ++ arch/mips/kernel/process.c | 15

[RFC PATCH 6/6] sparc: Use update_thread_flag()

This patch uses the new update_thread_flag() helper to simplify an if () set; else clear; construct. No functional change. Signed-off-by: Dave Martin <dave.mar...@arm.com> Cc: "David S. Miller" <da...@davemloft.net> --- arch/sparc/include/asm/elf_64.h | 5 + 1 fil

[RFC PATCH 6/6] sparc: Use update_thread_flag()

This patch uses the new update_thread_flag() helper to simplify an if () set; else clear; construct. No functional change. Signed-off-by: Dave Martin Cc: "David S. Miller" --- arch/sparc/include/asm/elf_64.h | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/

Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER

On Sun, Apr 15, 2018 at 11:16:04AM -0700, Linus Torvalds wrote: [...] > The other thing we should do is to get rid of the stupid padding. > Right now "struct siginfo" is pointlessly padded to 128 bytes. That is > completely insane, when it's always just zero in the kernel. Agreed, inside the

Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER

On Sun, Apr 15, 2018 at 11:16:04AM -0700, Linus Torvalds wrote: [...] > The other thing we should do is to get rid of the stupid padding. > Right now "struct siginfo" is pointlessly padded to 128 bytes. That is > completely insane, when it's always just zero in the kernel. Agreed, inside the

Re: [RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

On Wed, Apr 18, 2018 at 09:22:09AM -0500, Eric W. Biederman wrote: > Dave Martin <dave.mar...@arm.com> writes: > > > On Tue, Apr 17, 2018 at 02:37:38PM -0500, Eric W. Biederman wrote: [...] > >> My intention is to leave 0 instances of clear_siginfo in the >

Re: [RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

On Wed, Apr 18, 2018 at 09:22:09AM -0500, Eric W. Biederman wrote: > Dave Martin writes: > > > On Tue, Apr 17, 2018 at 02:37:38PM -0500, Eric W. Biederman wrote: [...] > >> My intention is to leave 0 instances of clear_siginfo in the > >> architecture specific

Re: [RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

On Tue, Apr 17, 2018 at 02:37:38PM -0500, Eric W. Biederman wrote: > Dave Martin <dave.mar...@arm.com> writes: > > > Hmmm > > > > memset()/clear_siginfo() may ensure that there are no uninitialised > > explicit fields except for those in inactive

Re: [RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

On Tue, Apr 17, 2018 at 02:37:38PM -0500, Eric W. Biederman wrote: > Dave Martin writes: > > > Hmmm > > > > memset()/clear_siginfo() may ensure that there are no uninitialised > > explicit fields except for those in inactive union members, but I'm not > > s

Re: [RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

On Sun, Apr 15, 2018 at 10:57:33AM -0500, Eric W. Biederman wrote: > > Call clear_siginfo to ensure every stack allocated siginfo is properly > initialized before being passed to the signal sending functions. > > Note: It is not safe to depend on C initializers to initialize struct > siginfo on

Re: [RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

On Sun, Apr 15, 2018 at 10:57:33AM -0500, Eric W. Biederman wrote: > > Call clear_siginfo to ensure every stack allocated siginfo is properly > initialized before being passed to the signal sending functions. > > Note: It is not safe to depend on C initializers to initialize struct > siginfo on

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 07:50:17PM +0100, Russell King - ARM Linux wrote: > On Fri, Apr 13, 2018 at 07:35:38PM +0100, Dave Martin wrote: > > If that's the case though, I don't see how a userspace testsuite is > > hitting this code path. Maybe I've misunderstood the context of

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 07:50:17PM +0100, Russell King - ARM Linux wrote: > On Fri, Apr 13, 2018 at 07:35:38PM +0100, Dave Martin wrote: > > If that's the case though, I don't see how a userspace testsuite is > > hitting this code path. Maybe I've misunderstood the context of

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 11:23:36AM -0700, Linus Torvalds wrote: > On Fri, Apr 13, 2018 at 10:54 AM, Russell King - ARM Linux > wrote: > > > > FPE_FLTINV means "floating point invalid operation". Does it really > > cover the case where hardware has failed, or is it intended

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 11:23:36AM -0700, Linus Torvalds wrote: > On Fri, Apr 13, 2018 at 10:54 AM, Russell King - ARM Linux > wrote: > > > > FPE_FLTINV means "floating point invalid operation". Does it really > > cover the case where hardware has failed, or is it intended to cover > > the case

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 06:54:08PM +0100, Russell King - ARM Linux wrote: > On Fri, Apr 13, 2018 at 06:08:28PM +0100, Dave Martin wrote: > > On Fri, Apr 13, 2018 at 09:33:17AM -0700, Linus Torvalds wrote: > > > On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM Linux > >

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 06:54:08PM +0100, Russell King - ARM Linux wrote: > On Fri, Apr 13, 2018 at 06:08:28PM +0100, Dave Martin wrote: > > On Fri, Apr 13, 2018 at 09:33:17AM -0700, Linus Torvalds wrote: > > > On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 09:33:17AM -0700, Linus Torvalds wrote: > On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM Linux > wrote: > > > > Yes, it does solve the problem at hand with strace - the exact patch I > > tested against 4.16 is below. > > Ok, good. > > >

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 09:33:17AM -0700, Linus Torvalds wrote: > On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM Linux > wrote: > > > > Yes, it does solve the problem at hand with strace - the exact patch I > > tested against 4.16 is below. > > Ok, good. > > > However, FPE_FLTUNK is not

Re: [PATCH] tools build: Use -Xpreprocessor instead of -Wp and leave pathnames intact

rocessor instead of -Wp, which allows > us to pass down an unmodified pathname. > > Cc: Jiri Olsa <jo...@kernel.org> > Cc: Dave Martin <dave.mar...@arm.com> > Cc: Arnaldo Carvalho de Melo <a...@redhat.com> > Cc: Ingo Molnar <mi...@kernel.org> > Signed-off-by: Wi

Re: [PATCH] tools build: Use -Xpreprocessor instead of -Wp and leave pathnames intact

rocessor instead of -Wp, which allows > us to pass down an unmodified pathname. > > Cc: Jiri Olsa > Cc: Dave Martin > Cc: Arnaldo Carvalho de Melo > Cc: Ingo Molnar > Signed-off-by: Will Deacon > --- > > As an aside, the way we currently pass the depfile to -MD appears to

Re: [PATCH v4 22/22] arm64: Add work around for Arm Cortex-A55 Erratum 1024718

> > Cc: Catalin Marinas <catalin.mari...@arm.com> > Cc: ckad...@codeaurora.org > Cc: Dave Martin <dave.mar...@arm.com> > Signed-off-by: Suzuki K Poulose <suzuki.poul...@arm.com> [...] > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > in

Re: [PATCH v4 22/22] arm64: Add work around for Arm Cortex-A55 Erratum 1024718

c: Catalin Marinas > Cc: ckad...@codeaurora.org > Cc: Dave Martin > Signed-off-by: Suzuki K Poulose [...] > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index 4e73c610a409..0fc097e2b72e 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b

Re: [PATCH v4 21/22] arm64: Delay enabling hardware DBM feature

y have the feature. Also, we print the > feature detection from the "matches" call back to make sure > we don't mislead the user when none of the CPUs could use the > feature. > > Cc: Catalin Marinas <catalin.mari...@arm.com> > Cc: Dave Martin <dave.mar...@arm.com&

Re: [PATCH v4 21/22] arm64: Delay enabling hardware DBM feature

y have the feature. Also, we print the > feature detection from the "matches" call back to make sure > we don't mislead the user when none of the CPUs could use the > feature. > > Cc: Catalin Marinas > Cc: Dave Martin > Signed-off-by: Suzuki K Poulose [...] Reviewed-by: Dave Martin

Re: [PATCH v4 15/22] arm64: capabilities: Change scope of VHE to Boot CPU feature

saves us some not-so-pretty > hooks and special code, just for verifying the conflict. > > The patch also makes the VHE capability entry depend on > CONFIG_ARM64_VHE. > > Cc: Marc Zyngier <marc.zyng...@arm.com> > Cc: Dave Martin <dave.mar...@arm.com> > Cc: Wi

Re: [PATCH v4 15/22] arm64: capabilities: Change scope of VHE to Boot CPU feature

saves us some not-so-pretty > hooks and special code, just for verifying the conflict. > > The patch also makes the VHE capability entry depend on > CONFIG_ARM64_VHE. > > Cc: Marc Zyngier > Cc: Dave Martin > Cc: Will Deacon > Signed-off-by: Suzuki K Poulose Reviewed-by: Dave Martin [...] Cheers ---Dave

Re: [PATCH v4 11/22] arm64: capabilities: Group handling of features and errata workarounds

On Tue, Mar 13, 2018 at 11:51:09AM +, Suzuki K Poulose wrote: > Now that the features and errata workarounds have the same > rules and flow, group the handling of the tables. > > Cc: Dave Martin <dave.mar...@arm.com> > Signed-off-by: Suzuki K Poulose <suzuki.poul...

Re: [PATCH v4 11/22] arm64: capabilities: Group handling of features and errata workarounds

On Tue, Mar 13, 2018 at 11:51:09AM +, Suzuki K Poulose wrote: > Now that the features and errata workarounds have the same > rules and flow, group the handling of the tables. > > Cc: Dave Martin > Signed-off-by: Suzuki K Poulose It looks like nothing signifcant has chan

Re: linux-next: manual merge of the arm64 tree with the asm-generic tree

On Wed, Mar 21, 2018 at 09:38:28AM +, Arnd Bergmann wrote: > On Wed, Mar 21, 2018 at 6:50 AM, Stephen Rothwell > wrote: > > Hi all, > > > > Today's linux-next merge of the arm64 tree got a conflict in: > > > > include/uapi/asm-generic/siginfo.h > > > > between

Re: linux-next: manual merge of the arm64 tree with the asm-generic tree

On Wed, Mar 21, 2018 at 09:38:28AM +, Arnd Bergmann wrote: > On Wed, Mar 21, 2018 at 6:50 AM, Stephen Rothwell > wrote: > > Hi all, > > > > Today's linux-next merge of the arm64 tree got a conflict in: > > > > include/uapi/asm-generic/siginfo.h > > > > between commit: > > > >

Re: [PATCH v3 21/22] arm64: Delay enabling hardware DBM feature

On Wed, Mar 07, 2018 at 05:39:09PM +, Suzuki K Poulose wrote: > On 09/02/18 18:58, Dave Martin wrote: > >On Fri, Feb 09, 2018 at 05:55:12PM +, Suzuki K Poulose wrote: > >>We enable hardware DBM bit in a capable CPU, very early in the > >>boot via __cpu_

Re: [PATCH v3 21/22] arm64: Delay enabling hardware DBM feature

On Wed, Mar 07, 2018 at 05:39:09PM +, Suzuki K Poulose wrote: > On 09/02/18 18:58, Dave Martin wrote: > >On Fri, Feb 09, 2018 at 05:55:12PM +, Suzuki K Poulose wrote: > >>We enable hardware DBM bit in a capable CPU, very early in the > >>boot via __cpu_

Re: [PATCH v3 15/22] arm64: capabilities: Change scope of VHE to Boot CPU feature

On Thu, Mar 08, 2018 at 12:10:22PM +, Suzuki K Poulose wrote: > On 12/02/18 17:17, Dave Martin wrote: > >On Fri, Feb 09, 2018 at 05:54:59PM +, Suzuki K Poulose wrote: > >>We expect all CPUs to be running at the same EL inside the kernel > >>with or without VHE

Re: [PATCH v3 15/22] arm64: capabilities: Change scope of VHE to Boot CPU feature

On Thu, Mar 08, 2018 at 12:10:22PM +, Suzuki K Poulose wrote: > On 12/02/18 17:17, Dave Martin wrote: > >On Fri, Feb 09, 2018 at 05:54:59PM +, Suzuki K Poulose wrote: > >>We expect all CPUs to be running at the same EL inside the kernel > >>with or without VHE

Re: Clang build of arm64 kernel fails

On Thu, Mar 01, 2018 at 09:45:24AM +, Robin Murphy wrote: > Hi Andrey, > > On 28/02/18 19:32, Andrey Konovalov wrote: > >Hi Marc! > > > >I've tried to pull in new upstream commits and the kernel build > >started failing for me with the following errors (see below). > > > >It seems that the

Re: Clang build of arm64 kernel fails

On Thu, Mar 01, 2018 at 09:45:24AM +, Robin Murphy wrote: > Hi Andrey, > > On 28/02/18 19:32, Andrey Konovalov wrote: > >Hi Marc! > > > >I've tried to pull in new upstream commits and the kernel build > >started failing for me with the following errors (see below). > > > >It seems that the

Re: [PATCH] arm64: cpufeature: Trim feature reporting and include PAN emulation

On Wed, Feb 21, 2018 at 02:39:55PM +, Mark Rutland wrote: > On Wed, Feb 21, 2018 at 11:18:27AM +0000, Dave Martin wrote: > > On Tue, Feb 20, 2018 at 02:46:24PM -0800, Kees Cook wrote: > > > The PAN emulation notification was only happening for non-boot CPUs > > &

Re: [PATCH] arm64: cpufeature: Trim feature reporting and include PAN emulation

On Wed, Feb 21, 2018 at 02:39:55PM +, Mark Rutland wrote: > On Wed, Feb 21, 2018 at 11:18:27AM +0000, Dave Martin wrote: > > On Tue, Feb 20, 2018 at 02:46:24PM -0800, Kees Cook wrote: > > > The PAN emulation notification was only happening for non-boot CPUs > > &

Re: [PATCH] arm64: cpufeature: Trim feature reporting and include PAN emulation

On Tue, Feb 20, 2018 at 02:46:24PM -0800, Kees Cook wrote: > The PAN emulation notification was only happening for non-boot CPUs > if CPU capabilities had already been configured. This seems to be the > wrong place, as it's system-wide and isn't attached to capabilities, > so its reporting didn't

Re: [PATCH] arm64: cpufeature: Trim feature reporting and include PAN emulation

On Tue, Feb 20, 2018 at 02:46:24PM -0800, Kees Cook wrote: > The PAN emulation notification was only happening for non-boot CPUs > if CPU capabilities had already been configured. This seems to be the > wrong place, as it's system-wide and isn't attached to capabilities, > so its reporting didn't

Re: [PATCH v3 15/22] arm64: capabilities: Change scope of VHE to Boot CPU feature

r verifying the conflict. > > Cc: Marc Zyngier <marc.zyng...@arm.com> > Cc: Dave Martin <dave.mar...@arm.com> > Cc: Will Deacon <will.dea...@arm.com> > Signed-off-by: Suzuki K Poulose <suzuki.poul...@arm.com> > --- > arch/arm64/include/asm/cpufeature.h |

Re: [PATCH v3 15/22] arm64: capabilities: Change scope of VHE to Boot CPU feature

r verifying the conflict. > > Cc: Marc Zyngier > Cc: Dave Martin > Cc: Will Deacon > Signed-off-by: Suzuki K Poulose > --- > arch/arm64/include/asm/cpufeature.h | 7 +++ > arch/arm64/include/asm/virt.h | 6 -- > arch/arm64/kernel/cpufeature.c |

Re: [PATCH v3 19/22] arm64: capabilities: Handle shared entries

method is robust against being > called multiple times. > > This also reverts the changes introduced by commit 67948af41f2e6818ed > ("arm64: capabilities: Handle duplicate entries for a capability"). > > Cc: Dave Martin <dave.mar...@arm.com> > Cc: Robin Murphy <r

Re: [PATCH v3 19/22] arm64: capabilities: Handle shared entries

method is robust against being > called multiple times. > > This also reverts the changes introduced by commit 67948af41f2e6818ed > ("arm64: capabilities: Handle duplicate entries for a capability"). > > Cc: Dave Martin > Cc: Robin Mu

Re: [PATCH v3 14/22] arm64: capabilities: Add support for features enabled early

te if the capability should be detected > early on the boot CPU. The infrastructure then ensures that such > capabilities are probed and "enabled" early on in the boot CPU > and, enabled on the subsequent CPUs. > > Cc: Julien Thierry <julien.thie...@arm.com> > Cc: Dave Martin

Re: [PATCH v3 14/22] arm64: capabilities: Add support for features enabled early

te if the capability should be detected > early on the boot CPU. The infrastructure then ensures that such > capabilities are probed and "enabled" early on in the boot CPU > and, enabled on the subsequent CPUs. > > Cc: Julien Thierry > Cc: Dave Martin > Cc: Will Deacon >

Re: [PATCH v3 21/22] arm64: Delay enabling hardware DBM feature

y have the feature. Also, we print the > feature detection from the "matches" call back to make sure > we don't mislead the user when none of the CPUs could use the > feature. > > Cc: Catalin Marinas <catalin.mari...@arm.com> > Cc: Dave Martin <dave.mar...@arm.com

Re: [PATCH v3 21/22] arm64: Delay enabling hardware DBM feature

y have the feature. Also, we print the > feature detection from the "matches" call back to make sure > we don't mislead the user when none of the CPUs could use the > feature. > > Cc: Catalin Marinas > Cc: Dave Martin > Signed-off-by: Suzuki K Poulose > --- >

Re: [PATCH v3 11/22] arm64: capabilities: Group handling of features and errata workarounds

On Fri, Feb 09, 2018 at 05:54:51PM +, Suzuki K Poulose wrote: > Now that the features and errata workarounds have the same > rules and flow, group the handling of the tables. > > Cc: Dave Martin <dave.mar...@arm.com> > Signed-off-by: Suzuki K Poulose <suzuki.poul...@a

Re: [PATCH v3 11/22] arm64: capabilities: Group handling of features and errata workarounds

On Fri, Feb 09, 2018 at 05:54:51PM +, Suzuki K Poulose wrote: > Now that the features and errata workarounds have the same > rules and flow, group the handling of the tables. > > Cc: Dave Martin > Signed-off-by: Suzuki K Poulose The naming gets a bit confusin

Re: [PATCH v3 10/22] arm64: capabilities: Allow features based on local CPU scope

uot; (maybe) > one or more CPUs (e.g, KPTI, Software prefetch). This patch > splits the feature detection to two phases : > > 1) Local CPU features are checked on all boot time active CPUs. > 2) System wide features are checked only once after all CPUs are > active. >

Re: [PATCH v3 10/22] arm64: capabilities: Allow features based on local CPU scope

uot; (maybe) > one or more CPUs (e.g, KPTI, Software prefetch). This patch > splits the feature detection to two phases : > > 1) Local CPU features are checked on all boot time active CPUs. > 2) System wide features are checked only once after all CPUs are > active. > &g

Re: [PATCH v3 09/22] arm64: capabilities: Split the processing of errata work arounds

ecks are run only once after all the boot time CPUs are active. > > Cc: Dave Martin <dave.mar...@arm.com> > Signed-off-by: Suzuki K Poulose <suzuki.poul...@arm.com> Otherwise, Reviewed-by: Dave Martin <dave.mar...@arm.com> > --- > arch/arm64/kernel/cpufeature

Re: [PATCH v3 09/22] arm64: capabilities: Split the processing of errata work arounds

ecks are run only once after all the boot time CPUs are active. > > Cc: Dave Martin > Signed-off-by: Suzuki K Poulose Otherwise, Reviewed-by: Dave Martin > --- > arch/arm64/kernel/cpufeature.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > >

Re: [PATCH v3 08/22] arm64: capabilities: Prepare for grouping features and errata work arounds

On Fri, Feb 09, 2018 at 05:54:45PM +, Suzuki K Poulose wrote: > We are about to group the handling of all capabilities (features > and errata workarounds). This patch open codes the wrapper routines > to make it easier to merge the handling. > > Cc: Dave Martin <dave.mar...

Re: [PATCH v3 08/22] arm64: capabilities: Prepare for grouping features and errata work arounds

On Fri, Feb 09, 2018 at 05:54:45PM +, Suzuki K Poulose wrote: > We are about to group the handling of all capabilities (features > and errata workarounds). This patch open codes the wrapper routines > to make it easier to merge the handling. > > Cc: Dave Martin > Signe

Re: [PATCH 1/2] arm64: capabilities: Allow flexibility in scope

On Fri, Feb 09, 2018 at 12:16:01PM +, Suzuki K Poulose wrote: > >>> I'm not sure we need extra comments or documentation; I just want > >>> to check that I've understood the patch correctly. > >> > >> So, would you prefer this split to the original patch ? > > > > I think splitting out this

Re: [PATCH 1/2] arm64: capabilities: Allow flexibility in scope

On Fri, Feb 09, 2018 at 12:16:01PM +, Suzuki K Poulose wrote: > >>> I'm not sure we need extra comments or documentation; I just want > >>> to check that I've understood the patch correctly. > >> > >> So, would you prefer this split to the original patch ? > > > > I think splitting out this

Re: [PATCH v2 16/20] arm64: Handle shared capability entries

On Thu, Feb 08, 2018 at 12:32:56PM +, Robin Murphy wrote: > On 08/02/18 12:01, Dave Martin wrote: > >On Thu, Feb 08, 2018 at 10:53:52AM +, Suzuki K Poulose wrote: > >>On 07/02/18 10:39, Dave Martin wrote: > >>>On Wed, Jan 31, 2018 at 06:28:03PM +, Suzu

Re: [PATCH v2 16/20] arm64: Handle shared capability entries

On Thu, Feb 08, 2018 at 12:32:56PM +, Robin Murphy wrote: > On 08/02/18 12:01, Dave Martin wrote: > >On Thu, Feb 08, 2018 at 10:53:52AM +, Suzuki K Poulose wrote: > >>On 07/02/18 10:39, Dave Martin wrote: > >>>On Wed, Jan 31, 2018 at 06:28:03PM +, Suzu

Re: [PATCH 1/2] arm64: capabilities: Allow flexibility in scope

On Thu, Feb 08, 2018 at 04:31:47PM +, Suzuki K Poulose wrote: > On 08/02/18 16:10, Dave Martin wrote: > >On Thu, Feb 08, 2018 at 12:12:37PM +, Suzuki K Poulose wrote: > >>So far we have restricted the scopes for the capabilities > >>as follows : > >> 1)

Re: [PATCH 1/2] arm64: capabilities: Allow flexibility in scope

On Thu, Feb 08, 2018 at 04:31:47PM +, Suzuki K Poulose wrote: > On 08/02/18 16:10, Dave Martin wrote: > >On Thu, Feb 08, 2018 at 12:12:37PM +, Suzuki K Poulose wrote: > >>So far we have restricted the scopes for the capabilities > >>as follows : > >> 1)

Re: [PATCH 1/2] arm64: capabilities: Allow flexibility in scope

ow flexibility of having > any scope for a capability. So, we now run through both > arm64_features and arm64_errata in two phases for detection: > > a) with SCOPE_LOCAL_CPU filter on each boot time enabled > CPUs. > b) with SCOPE_SYSTEM filter only once after all boot time >

Re: [PATCH 1/2] arm64: capabilities: Allow flexibility in scope

ow flexibility of having > any scope for a capability. So, we now run through both > arm64_features and arm64_errata in two phases for detection: > > a) with SCOPE_LOCAL_CPU filter on each boot time enabled > CPUs. > b) with SCOPE_SYSTEM filter only once after all boot time >

Re: [PATCH v2 16/20] arm64: Handle shared capability entries

t, all the entries should have the same "type". > > Cc: Dave Martin <dave.mar...@arm.com> > Cc: Will Deacon <will.dea...@arm.com> > Cc: Mark Rutland <mark.rutl...@arm.com> > Signed-off-by: Suzuki K Poulose <suzuki.poul...@arm.com> > --- [...] &g

<    1   2   3   4   5   6   7   8   9   10   >