On Wed, Jul 25, 2018 at 05:37:26PM +0100, Will Deacon wrote:
> On Wed, Jul 25, 2018 at 04:54:27PM +0100, Dave Martin wrote:
> > On Wed, Jul 25, 2018 at 02:45:11PM +0100, Will Deacon wrote:
> > > @@ -3476,7 +3478,8 @@ int restore_altstack(const stack_t __user *uss)
> > >
On Thu, Jul 26, 2018 at 05:06:34PM +0200, Sebastian Andrzej Siewior wrote:
> In v4.16-RT I noticed a number of warnings from task_fpsimd_load(). The
> code disables BH and expects that it is not preemptible. On -RT the
> task remains preemptible but remains the same CPU. This may corrupt the
> cont
On Wed, Jul 18, 2018 at 11:24:48AM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-07-18 11:12:10 [+0200], To Dave Martin wrote:
> > > > - if (may_use_simd()) {
> > > > + if (!IS_ENABLED(CONFIG_PREEMPT_RT_BASE) && may_use_simd()) {
> > >
&
On Wed, Jul 25, 2018 at 09:51:53AM +0100, Suzuki K Poulose wrote:
> On 07/25/2018 09:35 AM, Dirk Mueller wrote:
> >Since commit d3aec8a28be3b8 ("arm64: capabilities: Restrict KPTI
> >detection to boot-time CPUs") we rely on errata flags being already
> >populated during feature enumeration. The ord
On Wed, Jul 25, 2018 at 02:45:11PM +0100, Will Deacon wrote:
> The sigaltstack(2) system call fails with -ENOMEM if the new alternative
> signal stack is found to be smaller than SIGMINSTKSZ. On architectures
> such as arm64, where the native value for SIGMINSTKSZ is larger than
> the compat value,
o
> Cc: Oleg Nesterov
> Reported-by: Steve McIntyre
> Signed-off-by: Will Deacon
Reviewed-by: Dave Martin
> ---
> arch/arm64/include/asm/compat.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compa
begin().
>
> This patch replaces raw_cpu_read() with this_cpu_read() to protect
> against this race.
>
> Fixes: cb84d11e1625 ("arm64: neon: Remove support for nested or hardirq
> kernel-mode NEON")
> Acked-by: Ard Biesheuvel
> Reviewed-by: Dave Martin
> Reviewe
On Tue, Jan 23, 2018 at 12:27:54PM +, Suzuki K Poulose wrote:
> From: Dave Martin
>
> We issue the enable() call back for all CPU hwcaps capabilities
> available on the system, on all the CPUs. So far we have ignored
> the argument passed to the call back, which had a prototyp
On Tue, Jan 23, 2018 at 12:27:55PM +, Suzuki K Poulose wrote:
> We trigger CPU errata work around check on the boot CPU from
> smp_prepare_boot_cpu() to make sure that we run the checks only
> after the CPU feature infrastructure is initialised.
On the surface of it, this sounds like a bug fix
On Tue, Jan 23, 2018 at 03:07:18PM +, Suzuki K Poulose wrote:
> On 23/01/18 14:59, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:27:55PM +, Suzuki K Poulose wrote:
> >>We trigger CPU errata work around check on the boot CPU from
> >>smp_prepare_boot_cpu() t
On Tue, Jan 23, 2018 at 12:27:57PM +, Suzuki K Poulose wrote:
> We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
> to the userspace and the CPU hwcaps used by the kernel, which
> include cpu features and CPU errata work arounds.
>
> At the moment we have the following restrici
On Wed, Jan 24, 2018 at 06:45:01PM +, Suzuki K Poulose wrote:
> Dave,
>
> Thanks a lot for taking the time to review the patch and for
> opening up the discussion ! See my comments below.
>
> On 23/01/18 17:33, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:27:57PM
On Tue, Jan 23, 2018 at 03:38:37PM +, Suzuki K Poulose wrote:
> On 23/01/18 14:52, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:27:54PM +, Suzuki K Poulose wrote:
> >>From: Dave Martin
> >>
> >>We issue the enable() call back for all CPU hwcaps capa
On Tue, Jan 23, 2018 at 12:27:57PM +, Suzuki K Poulose wrote:
> We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
> to the userspace and the CPU hwcaps used by the kernel, which
> include cpu features and CPU errata work arounds.
>
> At the moment we have the following restrici
On Thu, Jan 25, 2018 at 05:08:58PM +, Suzuki K Poulose wrote:
> On 25/01/18 13:43, Dave Martin wrote:
[...]
> >>2) WHEN: When is the capability "enabled" or in other words, when does the
> >>kernel start using the capability. At the moment there is only
> &
On Tue, Jan 30, 2018 at 11:17:38AM +, Suzuki K Poulose wrote:
> On 26/01/18 10:10, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:27:58PM +, Suzuki K Poulose wrote:
> >>Add two different flags to indicate if the conflict of a capability
> >>on a late CPU wi
On Mon, Jan 29, 2018 at 05:22:26PM +, Suzuki K Poulose wrote:
> On 29/01/18 17:14, Dave Martin wrote:
> >On Fri, Jan 26, 2018 at 12:31:18PM +, Suzuki K Poulose wrote:
> >>On 26/01/18 11:47, Dave Martin wrote:
> >>>On Tue, Jan 23, 2018 at 12:28:01PM +, Su
On Fri, Jan 26, 2018 at 03:57:44PM +, Suzuki K Poulose wrote:
> On 26/01/18 14:16, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:28:06PM +, Suzuki K Poulose wrote:
> >>Add helpers for detecting an errata on list of midr ranges
> >>of affected CPUs.
> >
On Fri, Jan 26, 2018 at 04:05:24PM +, Suzuki K Poulose wrote:
> On 26/01/18 14:41, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:28:08PM +, Suzuki K Poulose wrote:
> >>We enable hardware DBM bit in a capable CPU, very early in the
> >>boot via __cpu_se
On Fri, Jan 26, 2018 at 04:29:53PM +, Suzuki K Poulose wrote:
> On 26/01/18 15:33, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:28:09PM +, Suzuki K Poulose wrote:
> >>Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
> >>from an erratum 1024
On Tue, Jan 30, 2018 at 03:38:44PM +, Suzuki K Poulose wrote:
> On 30/01/18 15:16, Dave Martin wrote:
> >On Fri, Jan 26, 2018 at 03:57:44PM +, Suzuki K Poulose wrote:
> >>On 26/01/18 14:16, Dave Martin wrote:
> >>>On Tue, Jan 23, 2018 at 12:28:06PM +, Suz
On Mon, Jan 15, 2018 at 05:49:47PM +, Russell King - ARM Linux wrote:
> On Thu, Jan 11, 2018 at 06:59:37PM -0600, Eric W. Biederman wrote:
> > Setting si_code to 0 results in a userspace seeing an si_code of 0.
> > This is the same si_code as SI_USER. Posix and common sense requires
> > that S
On Thu, Jan 25, 2018 at 05:56:02PM +, Suzuki K Poulose wrote:
> On 25/01/18 17:33, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:27:57PM +, Suzuki K Poulose wrote:
> >>We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
> >>to the userspace and
On Tue, Jan 23, 2018 at 12:27:58PM +, Suzuki K Poulose wrote:
> Add two different flags to indicate if the conflict of a capability
> on a late CPU with the current system state
>
> 1) Can a CPU have a capability when the system doesn't have it ?
>
> Most arm64 features could have this s
On Tue, Jan 23, 2018 at 12:27:59PM +, Suzuki K Poulose wrote:
> Now that each capability describes how to treat the conflicts
> of CPU cap state vs System wide cap state, we can unify the
> verification logic to a single place.
>
> Signed-off-by: Suzuki K Poulose
> ---
> arch/arm64/kernel/cp
On Tue, Jan 23, 2018 at 12:28:00PM +, Suzuki K Poulose wrote:
> While processing the list of capabilities, it is useful to
> filter out some of the entries based on the given type to
> allow better control. This can be used later for handling
> LOCAL vs SYSTEM wide capabilities and more.
>
> S
On Tue, Jan 23, 2018 at 12:28:01PM +, Suzuki K Poulose wrote:
> So far we have had separate routes for triggering errata and feature
"triggering errata" ? ;)
Maybe "[...] for determining whether to activate errata workarounds and
whether to enable feature capabilities."
> capabilities. Also,
On Tue, Jan 23, 2018 at 12:28:02PM +, Suzuki K Poulose wrote:
> Add type for features that are detected on individual CPUs,
> rather than on a system wide safe features. This behavior
feature
> is similar to that of a strict cpu erratum, where a later
> CPU is not allowed to boot if the syste
On Tue, Jan 23, 2018 at 12:28:03PM +, Suzuki K Poulose wrote:
> KPTI capability is a security feature which should be enabled
> when at least one CPU on the system needs it. Any late CPU
> which needs the kernel support, should be prevented from
> booting (and thus making the system unsecure) i
On Tue, Jan 23, 2018 at 12:28:04PM +, Suzuki K Poulose wrote:
> We are about to introduce generic MIDR range helpers. Clean
> up the existing helpers in errat handling, preparing them
errata/erratum
> to use generic version.
>
> Signed-off-by: Suzuki K Poulose
> ---
> arch/arm64/kernel/cpu
On Tue, Jan 23, 2018 at 12:28:05PM +, Suzuki K Poulose wrote:
> Add helpers for checking if the given CPU midr falls in a range
> of variants/revisions for a given model.
This doesn't describe what the patch does: instead, helpers are being
added for checking whether an MIDR falls in one of mu
On Tue, Jan 23, 2018 at 12:28:06PM +, Suzuki K Poulose wrote:
> Add helpers for detecting an errata on list of midr ranges
> of affected CPUs.
This doesn't describe what the patch does: instead, helpers are being
added for checking whether an MIDR falls in one of multiple affected
model(s) and
On Tue, Jan 23, 2018 at 12:28:08PM +, Suzuki K Poulose wrote:
> We enable hardware DBM bit in a capable CPU, very early in the
> boot via __cpu_setup. This doesn't give us a flexibility of
> optionally disable the feature, as the clearing the bit
> is a bit costly as the TLB can cache the setti
On Tue, Jan 23, 2018 at 12:28:09PM +, Suzuki K Poulose wrote:
> Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
> from an erratum 1024718, which causes incorrect updates when DBM/AP
> bits in a page table entry is modified without a break-before-make
> sequence. The work arou
On Thu, Jan 25, 2018 at 04:57:22PM +, Suzuki K Poulose wrote:
> On 25/01/18 15:36, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 03:38:37PM +, Suzuki K Poulose wrote:
> >>On 23/01/18 14:52, Dave Martin wrote:
> >>>On Tue, Jan 23, 2018 at 12:27:54PM +, Suzu
On Fri, Jan 26, 2018 at 12:10:11PM +, Suzuki K Poulose wrote:
> On 26/01/18 11:08, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:27:59PM +, Suzuki K Poulose wrote:
> >>Now that each capability describes how to treat the conflicts
> >>of CPU cap state vs Sy
On Fri, Jan 26, 2018 at 12:21:43PM +, Suzuki K Poulose wrote:
> On 26/01/18 11:22, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:28:00PM +, Suzuki K Poulose wrote:
> >>While processing the list of capabilities, it is useful to
> >>filter out some of the entr
On Fri, Jan 26, 2018 at 12:31:18PM +, Suzuki K Poulose wrote:
> On 26/01/18 11:47, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:28:01PM +, Suzuki K Poulose wrote:
> >>So far we have had separate routes for triggering errata and feature
> &g
On Fri, Jan 26, 2018 at 03:46:59PM +, Suzuki K Poulose wrote:
> On 26/01/18 12:25, Dave Martin wrote:
> >On Tue, Jan 23, 2018 at 12:28:03PM +, Suzuki K Poulose wrote:
> >>KPTI capability is a security feature which should be enabled
> >>when at least one CPU
On Mon, Jan 15, 2018 at 11:23:03AM -0600, Eric W. Biederman wrote:
> Dave Martin writes:
>
> > On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Biederman wrote:
> >> Setting si_code to 0 results in a userspace seeing an si_code of 0.
> >> This is the same si_code
On Mon, Jan 15, 2018 at 05:49:47PM +, Russell King - ARM Linux wrote:
> On Thu, Jan 11, 2018 at 06:59:37PM -0600, Eric W. Biederman wrote:
> > Setting si_code to 0 results in a userspace seeing an si_code of 0.
> > This is the same si_code as SI_USER. Posix and common sense requires
> > that S
On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote:
> Dave Martin writes:
>
> > On Mon, Jan 15, 2018 at 11:23:03AM -0600, Eric W. Biederman wrote:
> >> Dave Martin writes:
> >>
> >> > On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Bie
On Wed, Jan 17, 2018 at 11:57:09AM +, Russell King - ARM Linux wrote:
> On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote:
> > I will keep FPE_FIXME as a place holder until this gets sorted out.
> >
> > There is a second issue I am looking at in this location,
> > and maybe I d
>
> Fixes: commit 6a6efbb45b7d95c84 ("arm64: Verify CPU errata work arounds on
> hotplugged CPU")
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: Andre Przywara
> Cc: Catalin Marinas
> Cc: Dave Martin
> Signed-off-by: Suzuki K Poulose
> ---
> arch/
On Wed, Jan 17, 2018 at 01:22:19PM +, Suzuki K Poulose wrote:
> On 17/01/18 12:25, Dave Martin wrote:
> >On Wed, Jan 17, 2018 at 10:05:56AM +, Suzuki K Poulose wrote:
> >>When a CPU is brought up after we have finalised the system
> >>wide capabilities (i.e, fe
On Wed, Jan 17, 2018 at 12:37:52PM +, Russell King - ARM Linux wrote:
> On Wed, Jan 17, 2018 at 12:15:05PM +0000, Dave Martin wrote:
> > On Wed, Jan 17, 2018 at 11:57:09AM +, Russell King - ARM Linux wrote:
[...]
> > > VFP used to use force_sig_info(), but it seems to b
On Wed, Jan 17, 2018 at 03:49:59PM +, Russell King - ARM Linux wrote:
> On Wed, Jan 17, 2018 at 03:37:31PM +0000, Dave Martin wrote:
> > On Wed, Jan 17, 2018 at 12:37:52PM +, Russell King - ARM Linux wrote:
[...]
> > > I'd be more inclined to agree with you
On Wed, Jan 17, 2018 at 02:52:09PM +, Suzuki K Poulose wrote:
> On 17/01/18 14:38, Dave Martin wrote:
> >On Wed, Jan 17, 2018 at 01:22:19PM +, Suzuki K Poulose wrote:
> >>On 17/01/18 12:25, Dave Martin wrote:
> >>>On Wed, Jan 17, 2018 at 10:05:56AM
On Mon, Jan 15, 2018 at 11:23:03AM -0600, Eric W. Biederman wrote:
> Dave Martin writes:
>
> > On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Biederman wrote:
[...]
> >> Possible ABI fixes include:
> >> - Send the signal without siginfo
> >> - Don'
On Wed, Jan 17, 2018 at 11:24:06AM -0600, Eric W. Biederman wrote:
> Dave Martin writes:
[...]
> > Should si_code simply be ignored for the SIGKILL case?
>
> I know what x86 does in a similar case is it uses force_sig instead of
> force_sig_info. Then the generic code g
nion {
> struct {/* To be used for erratum handling only */
> u32 midr_model;
Cheers
---Dave
--8<--
>From 04a4bd998d02e339341db250e66b0d34a7c4e042 Mon Sep 17 00:00:00 2001
From: Dave Martin
Date: Thu, 18 Jan 2018 11:29:14 +
Subject: [PATCH] arm6
On Thu, Jan 18, 2018 at 12:08:43PM +, Robin Murphy wrote:
> On 18/01/18 12:00, Robin Murphy wrote:
> [...]
> >>+struct enable_arg {
> >>+ int (*enable)(struct arm64_cpu_capabilities const *);
> >>+ struct arm64_cpu_capabilities const *cap;
> >>+};
> >>+
> >>+static int __enable_cpu_capabi
On Mon, Jan 15, 2018 at 07:14:43AM +, Chen-Yu Tsai wrote:
> The A80 is a big.LITTLE SoC with 1 cluster of 4 Cortex-A7s and
> 1 cluster of 4 Cortex-A15s.
>
> This patch adds support to bring up the second cluster and thus all
> cores using custom platform SMP code. Core/cluster power down has n
On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Biederman wrote:
> Setting si_code to 0 results in a userspace seeing an si_code of 0.
> This is the same si_code as SI_USER. Posix and common sense requires
> that SI_USER not be a signal specific si_code. As such this use of 0
> for the si_code
o userspace, instead of the default entire structure.
> >>
> >> Cc: Catalin Marinas
> >> Cc: Will Deacon
> >> Cc: Christian Borntraeger
> >> Cc: Ingo Molnar
> >> Cc: James Morse
> >> Cc: "Peter Zijlstra (Intel)"
>
-Xpreprocessor 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
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:
> >
> > 0d7d2a23a347
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
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
PUs which really 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
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
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
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_se
On Thu, Nov 22, 2018 at 09:40:24AM +0800, Li, Aubrey wrote:
> On 2018/11/21 17:53, Peter Zijlstra wrote:
> > On Wed, Nov 21, 2018 at 09:19:36AM +0100, Peter Zijlstra wrote:
> >> On Wed, Nov 21, 2018 at 09:39:00AM +0800, Li, Aubrey wrote:
> Also; you were going to shop around with the other arc
>On Thu, Nov 22, 2018 at 12:01:54PM +, Dave Martin wrote:
> > > >> On Mon, Nov 19, 2018 at 05:25:12PM +0100, Vincent Whitchurch wrote:
> > > >> > st_info is currently overwritten after relocation and used to store
> > > >> > the
> > >
m].st_size;
> strlcpy(name, symname(kallsyms, symnum), KSYM_NAME_LEN);
> strlcpy(module_name, mod->name, MODULE_NAME_LEN);
> *exported = is_exported(name, *value, mod);
Based on the discussion here:
Reviewed-by: Dave Martin
(I still think this
On Mon, Nov 19, 2018 at 05:25:13PM +0100, Vincent Whitchurch wrote:
> Thumb-2 functions have the lowest bit set in the symbol value in the
> symtab. When kallsyms are generated for the vmlinux, the kallsyms are
> generated from the output of nm, and nm clears the lowest bit.
>
> $ arm-linux-gnue
On Mon, Nov 19, 2018 at 05:25:12PM +0100, Vincent Whitchurch wrote:
> st_info is currently overwritten after relocation and used to store the
> elf_type(). However, we're going to need it fix kallsyms on ARM's
> Thumb-2 kernels, so preserve st_info and overwrite the st_size field
> instead. st_si
On Tue, Nov 27, 2018 at 10:54:41PM +, Enke Chen wrote:
> [Repost as a series, as suggested by Andrew Morton]
>
> For simplicity and consistency, this patch provides an implementation
> for signal-based fault notification prior to the coredump of a child
> process. A new prctl command, PR_SET_P
On Thu, Nov 29, 2018 at 12:15:35AM +, Enke Chen wrote:
> Hi, Dave:
>
> Thanks for your comments. You have indeed missed some of the prior reviews
> and discussions. But that is OK.
>
> Please see my replies inline.
>
> On 11/28/18 7:19 AM, Dave Martin wrote:
> &
On Wed, Nov 14, 2018 at 12:40:44PM +0100, Florian Weimer wrote:
> * Dave Martin:
>
> > Fair points, though this is rather what I meant by "sane essentials".
> > Because there are strict limits on what can be done in the vDSO, it may
> > be more bloat-resistant
On Sun, Nov 18, 2018 at 12:17:51PM +0100, Christian Brauner wrote:
> With this patch an open() call on /proc/ will give userspace a handle
> to struct pid of the process associated with /proc/. This allows to
> maintain a stable handle on a process.
> I have been discussing various approaches exten
On Tue, Nov 13, 2018 at 12:27:45PM +0100, Vincent Whitchurch wrote:
> Thumb-2 functions have the lowest bit set in the symbol value in the
> symtab. When kallsyms are generated for the vmlinux, the kallsyms are
> generated from the output of nm, and nm clears the lowest bit.
>
> $ arm-linux-gnue
On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
[...]
> We can learn something from how Windows does things. On that system,
> what we think of as "libc" is actually two parts. (More, actually, but
> I'm simplifying.) At the lowest level, you have the semi-documented
> ntdll.dl
On Tue, Nov 13, 2018 at 12:58:39PM -0800, Andy Lutomirski wrote:
>
> > On Nov 13, 2018, at 11:39 AM, Dave Martin wrote:
> >
> > On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
> >
> > [...]
> >
> >> We can learn someth
On Mon, Jul 09, 2018 at 04:45:35PM +0800, Yandong.Zhao wrote:
> From: Yandong Zhao
>
> may_use_simd() can be called in any case and access kernel_neon_busy,
> for example: BUG_ON(!may_use_simd()). This patch ensures that
> migration will not occur during program access to kernel_neon_busy.
>
>
On Fri, Jul 06, 2018 at 05:39:00PM +0100, Suzuki K Poulose wrote:
> On 07/06/2018 04:09 PM, Marc Zyngier wrote:
> >On 06/07/18 14:49, Suzuki K Poulose wrote:
> >>On 04/07/18 23:03, Suzuki K Poulose wrote:
> >>>On 07/04/2018 04:51 PM, Will Deacon wrote:
> Hi Suzuki,
>
> On Fri, Jun 29,
On Mon, Jul 09, 2018 at 03:21:59PM +0100, Mark Rutland wrote:
> On Fri, Jul 06, 2018 at 05:38:45PM +0100, Will Deacon wrote:
> > On Mon, Jul 02, 2018 at 12:04:07PM +0100, Mark Rutland wrote:
> > > Now that all of the syscall logic works on the saved pt_regs, apply_ssbd
> > > can safely corrupt x0-x
On Tue, Jul 10, 2018 at 10:21:40AM +0800, Yandong.Zhao wrote:
> From: Yandong Zhao
>
> Operations for contexts where we do not want to do any checks for
> preemptions. Unless strictly necessary, always use this_cpu_read()
> instead. Because of the kernel_neon_busy here we have to make sure
> th
begin().
>
> This patch replaces raw_cpu_read() with this_cpu_read() to protect
> against this race.
>
> Signed-off-by: Yandong Zhao
Looks ok to me. You can add the following tags:
Fixes: cb84d11e1625 ("arm64: neon: Remove support for nested or hardirq
kernel-m
e execution of
> > raw_cpu_read() and the next task to be scheduled in on the initial
> > cpu calls kernel_neon_begin().
> >
> > This patch replaces raw_cpu_read() with this_cpu_read() to protect
> > against this race.
> >
> > Fixes: cb84d11e1625 (&quo
el archive
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/thread.html
[3]
http://linux-arm.org/git?p=linux-dm.git;a=shortlog;h=refs/heads/kvm-vhe-fpsimd/v11
Christoffer Dall (1):
KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change
Dave Martin (18):
arm64: fpsimd: Fix TIF_FOREIG
rmail/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
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/
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
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
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
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
ty.
>
> 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
s != ~0 here?
The subtle differences in evaluation semantics between #if and
other contexts here may well trip people up during maintenance...
With that, Reviewed-by: Dave Martin
Cheers
---Dave
>
> /* SCTLR_EL1 specific flags. */
> #define SCTLR_EL1_UCI
tion function, let's
> unify these with a common helper, providing a consistent order for
> clear/set operands, and the write skipping behaviour from
> change_cpacr(). Code will be migrated to the new helper in subsequent
> patches.
>
> Signed-off-by: Mark Rutland
> C
On Mon, May 14, 2018 at 10:46:26AM +0100, Mark Rutland wrote:
> Now that we have sysreg_clear_set(), we can consistently use this
> instead of config_sctlr_el1().
>
> Signed-off-by: Mark Rutland
> Cc: Catalin Marinas
> Cc: James Morse
> Cc: Will Deacon
Rev
s part of
> the conversion. Also, sve_user_enable() redundantly clears
> CPACR_EL1_ZEN_EL0EN before setting it; this is removed for clarity.
>
> Signed-off-by: Mark Rutland
> Cc: Catalin Marinas
> Cc: Dave Martin
> Cc: James Morse
> Cc: Will Deacon
Looks right to me.
R
n sequences like:
>
> if (system_supports_sve() && some_condition
> sve_user_disable();
>
> ... empty stubs are provided when support for SVE is not enabled.
>
> Signed-off-by: Mark Rutland
> Cc: Catalin Marinas
> Cc: Dave Martin
> Cc: Will Deacon
> ---
On Mon, May 14, 2018 at 10:46:32AM +0100, Mark Rutland wrote:
> Now that the syscall invocation logic is in C, we can migrate the rest
> of the syscall entry logic over, so that the entry assembly needn't look
> at the register values at all.
>
> Signed-off-by: Mark Rutland
> Cc: Catalin Marinas
interface to these syscalls.
Tentatively-reviewed-by: Dave Martin
>
> This patch takes the same approach for arm64.
>
> Signed-off-by: Mark Rutland
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/include/asm/unistd32.h | 4 ++--
> arch/arm64/kernel/ent
On Mon, May 14, 2018 at 10:46:30AM +0100, Mark Rutland wrote:
> As a first step towards invoking syscalls with a pt_regs argument,
> convert the raw syscall invocation logic to C. We end up with a bit more
> register shuffling, but the unified invocation logic means we can unify
> the tracing paths
same calling convention as sys_personality().
>
> This is necessary to enable conversion of arm64's syscall handling to
> use pt_regs wrappers.
>
> Signed-off-by: Mark Rutland
> Cc: Al Viro
> Cc: Dominik Brodowski
Reviewed-by: Dave Martin
> ---
> include/li
On Mon, May 14, 2018 at 10:46:33AM +0100, Mark Rutland wrote:
> We can zero GPRs x0 - x29 upon entry from EL0 to make it harder for
> userspace to control values consumed by speculative gadgets.
>
> We don't blat x30, since this is stashed much later, and we'll blat it
> before invoking C code.
>
On Mon, May 14, 2018 at 11:08:59AM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 11:00:53AM +0100, Dave Martin wrote:
> > On Mon, May 14, 2018 at 10:46:24AM +0100, Mark Rutland wrote:
> > > -/* Check all the bits are accounted for */
> > > -#define SCTLR_EL
101 - 200 of 663 matches
Mail list logo
