On Tue, Apr 23, 2019 at 11:59:44AM +0100, Julien Grall wrote:
> Hi Dave,
>
> On 4/17/19 3:01 PM, Dave Martin wrote:
> >On Wed, Apr 17, 2019 at 12:37:57PM +0100, Julien Grall wrote:
> >>Hi Dave,
> >>
> >>On 16/04/2019 13:30, Dave Martin wrote:
> >&g
On Wed, Apr 17, 2019 at 12:37:57PM +0100, Julien Grall wrote:
> Hi Dave,
>
> On 16/04/2019 13:30, Dave Martin wrote:
> >On Fri, Apr 12, 2019 at 06:14:20PM +0100, Julien Grall wrote:
[...]
> >>+
> >>+/*
> >>+ * Obtain the CPU FPSIMD context for use by
the changes done.
>
> Signed-off-by: Amit Daniel Kachhap
> Cc: Mark Rutland
> Cc: Marc Zyngier
> Cc: Christoffer Dall
> Cc: kvm...@lists.cs.columbia.edu
> ---
>
> Changes since v8:
> * Update vcpu->arch.flags to final enable state. [Dave Martin]
> * Change in
On Fri, Apr 12, 2019 at 06:14:20PM +0100, Julien Grall wrote:
> When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of
> the kernel may be able to use FPSIMD/SVE. This is for instance the case
> for crypto code.
>
> Any use of FPSIMD/SVE in the kernel are clearly marked by using
On Fri, Apr 12, 2019 at 06:14:19PM +0100, Julien Grall wrote:
> The only external user of fpsimd_save() and fpsimd_flush_cpu_state() is
> the KVM FPSIMD code.
>
> A follow-up patch will mandate hold of the FPSIMD context while
This is a bit hard to read without understanding the following patch.
by: Julien Grall
Good spot, thanks.
Reviewed-by: Dave Martin
>
> ---
> Changes in v2:
> - Patch added
> ---
> arch/arm64/include/asm/fpsimd.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include
On Thu, Apr 11, 2019 at 04:58:41PM +0100, Julien Grall wrote:
> Hi Dave,
>
> On 4/5/19 4:07 PM, Dave Martin wrote:
> >On Fri, Apr 05, 2019 at 10:02:45AM +0100, Julien Grall wrote:
> >>>>+#ifdef CONFIG_KERNEL_MODE_NEON
> >>>>+
> >>&g
On Fri, Apr 05, 2019 at 10:02:45AM +0100, Julien Grall wrote:
> Hi Dave,
>
> Thank you for the review.
>
> On 4/4/19 11:52 AM, Dave Martin wrote:
> >On Fri, Feb 08, 2019 at 04:55:13PM +, Julien Grall wrote:
> >>For RT-linux, it might be possible to use migra
On Fri, Feb 08, 2019 at 04:55:13PM +, Julien Grall wrote:
> When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of
> the kernel may be able to use FPSIMD/SVE. This is for instance the case
> for crypto code.
>
> Any use of FPSIMD/SVE in the kernel are clearly marked by using
On Thu, Mar 14, 2019 at 06:07:19PM +, Julien Grall wrote:
> Hi Sebastian,
>
> On 3/4/19 5:25 PM, Sebastian Andrzej Siewior wrote:
[...]
> >It would increase the softirq latency but the question is how bad would
> >it be. It would continue once the SIMD section is done.
>
> On Arm, the
gt; > > > > > "that prevents it from overlapping any other input or output."
> > > > > > > >
> > > > > > > > but then withdrawn as the warning was determined to be
> > > > > > > > harmless, and it
> >
On Mon, Mar 04, 2019 at 04:38:18PM +0530, Amit Daniel Kachhap wrote:
>
> Hi Dave,
>
> On 3/1/19 4:54 PM, Dave P Martin wrote:
> >On Fri, Mar 01, 2019 at 10:37:54AM +, Amit Daniel Kachhap wrote:
> >>Hi,
> >>
> >>On 2/21/19 9:24 PM, Dave Martin w
On Tue, Feb 19, 2019 at 02:54:28PM +0530, Amit Daniel Kachhap wrote:
> From: Mark Rutland
>
> When pointer authentication is supported, a guest may wish to use it.
> This patch adds the necessary KVM infrastructure for this to work, with
> a semi-lazy context switch of the pointer auth state.
>
On Tue, Feb 19, 2019 at 02:54:31PM +0530, Amit Daniel Kachhap wrote:
> This is a runtime capabality for KVM tool to enable Armv8.3 Pointer
> Authentication in guest kernel. A command line option --ptrauth is
> required for this.
>
> Signed-off-by: Amit Daniel Kachhap
> ---
>
On Tue, Feb 19, 2019 at 02:54:29PM +0530, Amit Daniel Kachhap wrote:
> This feature will allow the KVM guest to allow the handling of
> pointer authentication instructions or to treat them as undefined
> if not set. It uses the existing vcpu API KVM_ARM_VCPU_INIT to
> supply this parameter instead
ters to default values but they are
> left like that as they are conditionally accessible (set/get).
>
> Signed-off-by: Amit Daniel Kachhap
> Cc: Mark Rutland
> Cc: Marc Zyngier
> Cc: Christoffer Dall
> Cc: kvm...@lists.cs.columbia.edu
> ---
> This patch needs patch [1]
On Tue, Feb 19, 2019 at 02:54:27PM +0530, Amit Daniel Kachhap wrote:
> Save host MDCR_EL2 value during kvm HYP initialisation and restore
> after every switch from host to guest. There should not be any
> change in functionality due to this.
>
> The value of mdcr_el2 is now stored in struct
On Tue, Feb 19, 2019 at 02:54:26PM +0530, Amit Daniel Kachhap wrote:
> From: Mark Rutland
>
> When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which
> is a constant value. This works today, as the host HCR_EL2 value is
> always the same, but this will get in the way of
On Thu, Feb 21, 2019 at 12:29:42PM +, Mark Rutland wrote:
> On Tue, Feb 19, 2019 at 02:54:28PM +0530, Amit Daniel Kachhap wrote:
> > From: Mark Rutland
> >
> > When pointer authentication is supported, a guest may wish to use it.
> > This patch adds the necessary KVM infrastructure for this
On Wed, Feb 13, 2019 at 05:52:27PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-02-13 16:40:00 [+0100], Ard Biesheuvel wrote:
> > > > This is equal what x86 is currently doing. The naming is slightly
> > > > different, there is irq_fpu_usable().
> > >
> > > Yes, I think it's basically the
On Wed, Feb 13, 2019 at 04:42:11PM +, Kevin Brodsky wrote:
> (+Cc other people with MTE experience: Branislav, Ruben)
[...]
> >I'm wondering whether we can piggy-back on existing concepts.
> >
> >We could say that recolouring memory is safe when and only when
> >unmapping of the page or
On Wed, Feb 13, 2019 at 04:40:00PM +0100, Ard Biesheuvel wrote:
> On Wed, 13 Feb 2019 at 16:36, Dave Martin wrote:
> >
> > On Wed, Feb 13, 2019 at 03:30:29PM +0100, Sebastian Andrzej Siewior wrote:
> > > On 2019-02-08 16:55:13 [+], Julien Grall wrote:
> > &
On Wed, Feb 13, 2019 at 03:30:29PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-02-08 16:55:13 [+], Julien Grall wrote:
> > When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of
> > the kernel may be able to use FPSIMD/SVE. This is for instance the case
> > for crypto
On Tue, Feb 12, 2019 at 06:02:24PM +, Catalin Marinas wrote:
> On Mon, Feb 11, 2019 at 12:32:55PM -0800, Evgenii Stepanov wrote:
> > On Mon, Feb 11, 2019 at 9:28 AM Kevin Brodsky wrote:
> > > On 19/12/2018 12:52, Dave Martin wrote:
[...]
> > > > * A sing
On Mon, Feb 11, 2019 at 11:35:12AM +, Catalin Marinas wrote:
> Hi Dave,
>
> On Wed, Dec 12, 2018 at 05:01:12PM +, Dave P Martin wrote:
> > On Mon, Dec 10, 2018 at 01:50:57PM +0100, Andrey Konovalov wrote:
> > > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> >
On Fri, Jan 18, 2019 at 05:27:29PM +, Julien Thierry wrote:
>
>
> On 18/01/2019 16:35, Dave Martin wrote:
> > On Tue, Jan 08, 2019 at 02:07:30PM +, Julien Thierry wrote:
> >> Instead disabling interrupts by setting the PSR.I bit, use a priority
>
On Fri, Jan 18, 2019 at 04:37:36PM +, Russell King - ARM Linux admin wrote:
> On Fri, Jan 18, 2019 at 04:00:27PM +, Andrew Murray wrote:
> > A common pattern found in header files is a function declaration dependent
> > on a CONFIG_ option being enabled, followed by an empty function for
On Tue, Jan 08, 2019 at 02:07:30PM +, Julien Thierry wrote:
> Instead disabling interrupts by setting the PSR.I bit, use a priority
> higher than the one used for interrupts to mask them via PMR.
>
> When using PMR to disable interrupts, the value of PMR will be used
> instead of PSR.[DAIF]
On Tue, Jan 08, 2019 at 05:58:59PM +, Julien Thierry wrote:
>
>
> On 08/01/2019 16:45, Dave Martin wrote:
> > On Tue, Jan 08, 2019 at 03:51:18PM +, Marc Zyngier wrote:
> >> On 08/01/2019 15:40, Dave Martin wrote:
> >>> On Tue, Jan 08, 2019 at 02
On Tue, Jan 08, 2019 at 05:16:43PM +, Marc Zyngier wrote:
> On 08/01/2019 16:45, Dave Martin wrote:
> > On Tue, Jan 08, 2019 at 03:51:18PM +, Marc Zyngier wrote:
> >> On 08/01/2019 15:40, Dave Martin wrote:
> >>> On Tue, Jan 08, 2019 at 02:07:30
On Tue, Jan 08, 2019 at 03:51:18PM +, Marc Zyngier wrote:
> On 08/01/2019 15:40, Dave Martin wrote:
> > On Tue, Jan 08, 2019 at 02:07:30PM +, Julien Thierry wrote:
> >> Instead disabling interrupts by setting the PSR.I bit, use a priority
> >> higher than
On Tue, Jan 08, 2019 at 02:07:30PM +, Julien Thierry wrote:
> Instead disabling interrupts by setting the PSR.I bit, use a priority
> higher than the one used for interrupts to mask them via PMR.
>
> When using PMR to disable interrupts, the value of PMR will be used
> instead of PSR.[DAIF]
On Thu, Jan 03, 2019 at 05:48:31PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 03, 2019 at 10:38:16AM -0600, Jeremy Linton wrote:
> > On 01/03/2019 03:38 AM, Greg Kroah-Hartman wrote:
> > > On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote:
> > > > There is a lot of variation in the
with existing usage,
remains the canonical way to get the common definitions for
SVE_VQ_MIN, sve_vq_from_vl() etc., both in userspace and in the
kernel: relying on these being defined as a side effect of
including just was never intended to be safe.
Signed-off-by: Dave Martin
---
Changes since v1
the SVE
header in the signal frame, not in the ptrace regset.
This patch fixes the definition to use the ptrace header structure
struct user_sve_header instead.
By good fortune, the two structures are the same size anyway, so
there is no functional or ABI change.
Signed-off-by: Dave Martin
namespaced.
The extra header guard in sve_context.h was considered redundant and is
now gone, so patch 1 (kbuild: install_headers.sh: Strip _UAPI from
#if-defined() guards) from the previous version of the series has been
dropeed.
Dave Martin (2):
arm64/sve: ptrace: Fix SVE_PT_REGS_OFFSET
On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote:
> There is a lot of variation in the Arm ecosystem. Because of this,
> there exist possible cases where the kernel cannot authoritatively
> determine if a machine is vulnerable.
>
> Rather than guess the vulnerability status in cases
On Thu, Jan 03, 2019 at 03:45:47PM +0800, Pi-Hsun Shih wrote:
> For syscall number smaller than 0xf, arm calls sys_ni_syscall
> instead of arm_syscall in arch/arm/kernel/entry-common.S, which returns
> -ENOSYS instead of raising SIGILL. Mirror this behavior for compat
> syscalls in arm64.
>
>
On Wed, Dec 19, 2018 at 03:11:52PM +, Szabolcs Nagy wrote:
> On 18/12/2018 12:14, Dave Martin wrote:
> > On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote:
[...]
> >>>> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type
> >>&g
On Tue, Dec 18, 2018 at 05:59:38PM +, Catalin Marinas wrote:
> On Tue, Dec 18, 2018 at 04:03:38PM +0100, Andrey Konovalov wrote:
> > On Wed, Dec 12, 2018 at 4:02 PM Catalin Marinas
> > wrote:
> > > The summary of our internal discussions (mostly between kernel
> > > developers) is that we
to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Dave-Martin/arm64-sve-UAPI-Disentangle-ptrace-h-from-sigcontext-h/20181214-225154
> base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.
On Fri, Dec 14, 2018 at 06:13:33PM +, Szabolcs Nagy wrote:
> On 11/12/2018 19:26, Dave Martin wrote:
> > This patch refactors the UAPI header definitions for the Arm SVE
> > extension to avoid multiple-definition problems when userspace mixes its
> > own sig
On Fri, Dec 14, 2018 at 10:41:42AM +, Steven Price wrote:
> On 14/12/2018 10:36, Will Deacon wrote:
> > On Fri, Dec 14, 2018 at 10:34:31AM +, Steven Price wrote:
> >> On 06/12/2018 23:44, Jeremy Linton wrote:
> >>> From: Mian Yousaf Kaukab
> >>>
> >>> Return status based no ssbd_state and
On Wed, Dec 12, 2018 at 09:48:03AM -0600, Jeremy Linton wrote:
> Hi Dave,
>
> Thanks for looking at this!
>
> On 12/13/2018 06:07 AM, Dave Martin wrote:
> >On Thu, Dec 06, 2018 at 05:44:02PM -0600, Jeremy Linton wrote:
> >>Part of this series was originally by Mian
On Thu, Dec 06, 2018 at 05:44:02PM -0600, Jeremy Linton wrote:
> Part of this series was originally by Mian Yousaf Kaukab.
>
> Arm64 machines should be displaying a human readable
> vulnerability status to speculative execution attacks in
> /sys/devices/system/cpu/vulnerabilities
Is there any
On Mon, Dec 10, 2018 at 02:30:43PM +, Vincenzo Frascino wrote:
> On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x hence
> the userspace (EL0) is allowed to set a non-zero value in the
> top byte but the resulting pointers are not allowed at the
> user-kernel syscall ABI boundary.
>
On Mon, Dec 10, 2018 at 01:50:57PM +0100, Andrey Konovalov wrote:
> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> tags into the top byte of each pointer. Userspace programs (such as
> HWASan, a memory debugging tool [1]) might use this feature and pass
> tagged user
On Fri, Dec 07, 2018 at 06:39:29PM +, Kristina Martsenko wrote:
> Add two new ptrace regsets, which can be used to request and change the
> pointer authentication keys of a thread. NT_ARM_PACA_KEYS gives access
> to the instruction/data address keys, and NT_ARM_PACG_KEYS to the
> generic
On Fri, Dec 07, 2018 at 06:39:28PM +, Kristina Martsenko wrote:
> Add an arm64-specific prctl to allow a thread to reinitialize its
> pointer authentication keys to random values. This can be useful when
> exec() is not used for starting new processes, to ensure that different
> processes
to the current handling of #ifndef _UAPI_FOO.
Dave Martin (3):
kbuild: install_headers.sh: Strip _UAPI from #if-defined() guards
arm64/sve: ptrace: Fix SVE_PT_REGS_OFFSET definition
arm64/sve: Disentangle from
arch/arm64/include/uapi/asm/ptrace.h | 39 ++---
arch/arm64
with existing usage,
remains the canonical way to get the common definitions for
SVE_VQ_MIN, sve_vq_from_vl() etc., both in userspace and in the
kernel: relying on these being defined as a side effect of
including just was never intended to be safe.
Signed-off-by: Dave Martin
---
arch/arm64/include
patch adds similar logic so that the _UAPI prefix is also
stripped from guard directives written using "#if defined()" etc.
This is not completely foolproof, but will work for simple cases of
using #if defined() to guard against inappropriate header inclusion.
Signed-off-by: Dave
the SVE
header in the signal frame, not in the ptrace regset.
This patch fixes the definition to use the ptrace header structure
struct user_sve_header instead.
By good fortune, the to structures are the same size anyway, so
there is no functional or ABI change.
Signed-off-by: Dave Martin
---
arch
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 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 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,
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,
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.
>
> $
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.
>
> $
t; 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 is a bit gross, bu
t; 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 is a bit gross, bu
>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
> > >
>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
> > >
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
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
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.
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.
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
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
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 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 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 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, 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
>
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
>
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.
>
> $
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.
>
> $
On Tue, Nov 06, 2018 at 12:29:33PM +, Mark Rutland wrote:
> On Tue, Nov 06, 2018 at 11:32:50AM +, Dave P Martin wrote:
> > On Tue, Nov 06, 2018 at 11:00:19AM +, Mark Rutland wrote:
> > > On Tue, Nov 06, 2018 at 08:57:51AM +, Daniel Thompson wrote:
> > > > On Tue, Nov 06, 2018 at
On Tue, Nov 06, 2018 at 12:29:33PM +, Mark Rutland wrote:
> On Tue, Nov 06, 2018 at 11:32:50AM +, Dave P Martin wrote:
> > On Tue, Nov 06, 2018 at 11:00:19AM +, Mark Rutland wrote:
> > > On Tue, Nov 06, 2018 at 08:57:51AM +, Daniel Thompson wrote:
> > > > On Tue, Nov 06, 2018 at
On Thu, Aug 09, 2018 at 01:38:12PM +0100, Will Deacon wrote:
> On Thu, Aug 09, 2018 at 01:34:57PM +0100, Dave Martin wrote:
> > On Wed, Aug 08, 2018 at 01:34:09PM +0100, Catalin Marinas wrote:
> > > On Tue, Aug 07, 2018 at 11:24:34AM +0100, Marc Zyngier wrote:
> > >
On Thu, Aug 09, 2018 at 01:38:12PM +0100, Will Deacon wrote:
> On Thu, Aug 09, 2018 at 01:34:57PM +0100, Dave Martin wrote:
> > On Wed, Aug 08, 2018 at 01:34:09PM +0100, Catalin Marinas wrote:
> > > On Tue, Aug 07, 2018 at 11:24:34AM +0100, Marc Zyngier wrote:
> > >
On Wed, Aug 08, 2018 at 01:34:09PM +0100, Catalin Marinas wrote:
> On Tue, Aug 07, 2018 at 11:24:34AM +0100, Marc Zyngier wrote:
> > On 07/08/18 11:05, Dave Martin wrote:
> > > On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngier wrote:
> > >> It recently came to li
On Wed, Aug 08, 2018 at 01:34:09PM +0100, Catalin Marinas wrote:
> On Tue, Aug 07, 2018 at 11:24:34AM +0100, Marc Zyngier wrote:
> > On 07/08/18 11:05, Dave Martin wrote:
> > > On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngier wrote:
> > >> It recently came to li
On Tue, Aug 07, 2018 at 01:12:03PM +0100, Robin Murphy wrote:
> On 07/08/18 11:30, Dave Martin wrote:
> >On Tue, Aug 07, 2018 at 11:24:34AM +0100, Marc Zyngier wrote:
> >>On 07/08/18 11:05, Dave Martin wrote:
> >>>On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngier
On Tue, Aug 07, 2018 at 01:12:03PM +0100, Robin Murphy wrote:
> On 07/08/18 11:30, Dave Martin wrote:
> >On Tue, Aug 07, 2018 at 11:24:34AM +0100, Marc Zyngier wrote:
> >>On 07/08/18 11:05, Dave Martin wrote:
> >>>On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngier
On Tue, Aug 07, 2018 at 11:24:34AM +0100, Marc Zyngier wrote:
> On 07/08/18 11:05, Dave Martin wrote:
> > On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngier wrote:
> >> It recently came to light that userspace can execute WFI, and that
> >> the arm64 kernel doesn t
On Tue, Aug 07, 2018 at 11:24:34AM +0100, Marc Zyngier wrote:
> On 07/08/18 11:05, Dave Martin wrote:
> > On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngier wrote:
> >> It recently came to light that userspace can execute WFI, and that
> >> the arm64 kernel doesn t
On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngier wrote:
> It recently came to light that userspace can execute WFI, and that
> the arm64 kernel doesn trap this event. This sounds rather benign,
> but the kernel should decide when it wants to wait for an interrupt,
> and not userspace.
>
>
On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngier wrote:
> It recently came to light that userspace can execute WFI, and that
> the arm64 kernel doesn trap this event. This sounds rather benign,
> but the kernel should decide when it wants to wait for an interrupt,
> and not userspace.
>
>
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
>
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
>
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 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)
&
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
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
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
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
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
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
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()) {
> > >
&
201 - 300 of 1073 matches
Mail list logo
