On Mon, May 14, 2018 at 01:06:10PM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 12:56:09PM +0100, Robin Murphy wrote:
> > On 14/05/18 12:20, Dave Martin wrote:
> > > On Mon, May 14, 2018 at 11:08:59AM +0100, Mark Rutland wrote:
> > > > On Mon, May 14, 2018 at
On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 12:07:18PM +0100, Dave Martin wrote:
> > 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,
> > &
On Mon, May 14, 2018 at 12:58:05PM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 12:07:30PM +0100, Dave Martin wrote:
> > On Mon, May 14, 2018 at 10:46:32AM +0100, Mark Rutland wrote:
>
> > > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
>
t I'm interested to know what people
think about the approach.
Cheers
---Dave
Dave Martin (11):
prctl: Support movement of arch prctls out of common code
arm64: Move arch-specific prctls out of core code
MIPS: Remove unused task argument from prctl functions
MIPS: Move arch-specific prctls o
Some ia64-specific prctl backends take a task argument that is
redundant, since the only thing ever passed is "current".
This patch gets rid of the redundant arguments.
No functional change.
Signed-off-by: Dave Martin
Cc: Tony Luck
Cc: Fenghua Yu
---
arch/ia64/include/asm/proce
Architecture backends for the PT_SET_UNALIGN and PR_GET_UNALIGN
prctl() calls take a task argument that is redundant, since the
only thing ever passed is "current".
This patch gets rid of the redundant arguments.
No functional change.
Signed-off-by: Dave Martin
Cc: Kees Cook
Cc: And
.
Because this is hardly hot-path code, there is no strong reason to
inline the arch backends for these operations, so this patch also
pushes them down into the arch trees as proper C functions, and
regularises the style of the backends somewhat.
Signed-off-by: Dave Martin
Cc: Kees Cook
Cc: Andrew
This patch moves the powerpc-specific prctl call implementations
out of core code and removes redundant boilerplate associated with
them.
No functional change.
Signed-off-by: Dave Martin
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
---
arch/powerpc/Kconfig
This patch moves the ia64-specific prctl call implementations out
of core code and removes redundant boilerplate associated with
them.
No functional change.
Signed-off-by: Dave Martin
Cc: Tony Luck
Cc: Fenghua Yu
---
arch/ia64/Kconfig | 1 +
arch/ia64/include/asm/processor.h
This patch moves the x86-specific prctl call implementations out
of core code and removes redundant boilerplate associated with
them.
No functional change.
Signed-off-by: Dave Martin
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
---
arch/x
Some MIPS-specific prctl backends take a task argument that is
redundant, since the only thing ever passed is "current".
This patch gets rid of the redundant arguments.
No functional change.
Signed-off-by: Dave Martin
Cc: Ralf Baechle
Cc: James Hogan
---
arch/mips/include/asm/p
Some powerpc-specific prctl backends take a task argument that is
redundant, since the only thing ever passed is "current".
This patch gets rid of the redundant arguments.
No functional change.
Signed-off-by: Dave Martin
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michae
prctl_arch() if an
unrecognised option is encountered.
(arch_prctl() would have been a nicer name, but it conflicts with the
pre-existing syscall of the same name on x86, particularly in the um
code.)
No functional change.
Signed-off-by: Dave Martin
Cc: Andrew Morton
Cc: Benjamin Herrenschmidt
This patch moves the MIPS-specific prctl call implementations out
of core code and removes redundant boilerplate associated with
them.
No functional change.
Signed-off-by: Dave Martin
Cc: Ralf Baechle
Cc: James Hogan
---
arch/mips/Kconfig | 1 +
arch/mips/include/asm
This patch moves the arm64-specific prctl call implementations out
of core code and removes redundant boilerplate associated with
them.
No functional change.
Signed-off-by: Dave Martin
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm
On Fri, Jun 01, 2018 at 11:29:13AM +0100, Mark Rutland wrote:
> On Wed, May 16, 2018 at 10:01:32AM +0100, Dave Martin wrote:
> > On Tue, May 15, 2018 at 05:33:52PM +0100, Mark Rutland wrote:
> > > On Tue, May 15, 2018 at 01:19:26PM +0100, Dave Martin wrote:
> > > >
On Tue, Jun 12, 2018 at 07:43:50PM +0100, Linus Torvalds wrote:
> On Tue, Jun 12, 2018 at 7:03 AM Paolo Bonzini wrote:
> >
> > git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
>
> Grr. Several tedious conflicts. I fixed them all up, and they all
> looked trivial, but since most of t
On Thu, May 17, 2018 at 02:40:06PM +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
Also,
On Thu, May 17, 2018 at 07:19:43PM +0100, Dave Martin wrote:
[...]
> kernel_neon_begin() could then do
>
> local_fpsimd_context_lock();
>
> /* ... */
>
> preempt_disable();
> local_unlock(fpsimd_context_lock);
>
> ... with th
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 still
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 authen
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 po
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 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 ag
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
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 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 can
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 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 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 sigcontext.h
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/in
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
o 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/
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, 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, 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 w
tably
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_O
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 sin
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
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
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 08:
On Fri, Jul 13, 2018 at 07:49:38PM +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, Mar 18, 2015 at 02:20:22PM +, Daniel Thompson wrote:
> Currently the magic SysRq functions can accessed by sending a break on
> the serial port. Unfortunately some networked serial proxies make it
> difficult to send a break meaning SysRq functions cannot be used. This
> patch provides
On Wed, Mar 18, 2015 at 02:20:21PM +, Daniel Thompson wrote:
> This patchset provides a pseudo-NMI for arm64 kernels by reimplementing
> the irqflags macros to modify the GIC PMR (the priority mask register is
> accessible as a system register on GICv3 and later) rather than the
> PSR. The pseu
On Fri, Mar 20, 2015 at 06:47:18PM +0300, Dmitry Osipenko wrote:
> This patch not tested. I assume that firmware save/restore cp15
> context, i.e. it doesn't require switching to LE before smc call and
> restore endianness after.
That assumption should be valid.
However, I think this patch must b
On Tue, Mar 31, 2015 at 11:22:29AM -0400, Nicolas Pitre wrote:
> On Mon, 30 Mar 2015, Ard Biesheuvel wrote:
>
> > On 30 March 2015 at 16:13, Michal Marek wrote:
[...]
> > > What you could do is to add a Kconfig option to arch/arm/Kconfig adding
> > > -ffunction-sections to the compiler flags. T
On Tue, Mar 31, 2015 at 02:42:24PM -0400, Nicolas Pitre wrote:
> On Tue, 31 Mar 2015, Dave Martin wrote:
[...]
> > We'd need to avoid pruning needed code that has no explicit caller,
> > and functions that are part of the kernel/module ABI but not used
> > within vmlin
Apologies for the slow reply... :/
Anyway,
On Mon, Mar 23, 2015 at 06:47:53PM +, Daniel Thompson wrote:
> On 20/03/15 15:45, Dave Martin wrote:
> >On Wed, Mar 18, 2015 at 02:20:21PM +, Daniel Thompson wrote:
> >>This patchset provides a pseudo-NMI for arm64 kernels
ster
> implementation.
> Change to use is_wide_instruction() in do_alignment() and remove
> IS_T32().
Reviewed-by: Dave Martin
The existing code is correct, but the comment is indeed wrong.
Consolidating this with one of the other existing macros makes sense.
!__opcode_is_thumb16() could also be u
On Mon, Apr 13, 2015 at 10:47:24PM +0800, Yingjoe Chen wrote:
> On Mon, 2015-04-13 at 13:48 +0100, Dave Martin wrote:
> > On Fri, Apr 10, 2015 at 10:05:41PM +0800, Yingjoe Chen wrote:
> > >
> > > I first notice the comment is incorrect, then I realize there's anot
cted, otherwise
show_stack() is used as a fallback.
Signed-off-by: Dave Martin
---
For arches that don't need anything except the stack pointer to
start the backtrace, we might be able to define a generic
arch_dump_backtrace() that invokes show_stack with sp instead of
just assuming the sp is
Hi,
On Thu, Jun 04, 2015 at 05:35:04PM +0800, Yang Yingliang wrote:
> This patch provides the ability to boot using a device tree that is appended
> to the raw binary Image (e.g. cat Image .dtb > Image_w_dtb).
>
> Both BE and LE conditions are tested.
>
> Got references from e2a6a3aa ("ARM: zIma
-May/579353.html
Christoffer Dall (1):
KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change
Dave Martin (17):
arm64: fpsimd: Fix TIF_FOREIGN_FPSTATE after invalidating cpu regs
thread_info: Add update_thread_flag() helpers
arm64: Use update{,_tsk}_thread_flag()
KVM: arm64: Convert l
On Mon, May 21, 2018 at 07:28:26PM +0100, Will Deacon wrote:
> Hi Dave,
>
> On Mon, May 14, 2018 at 06:14:17PM +0100, Dave Martin wrote:
> > The core framework for the prctl() syscall is unloved and looking
> > rather crusty these days. It also relies on defining ancillary
&
On Wed, May 23, 2018 at 04:31:56PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-05-17 19:19:43 [+0100], Dave Martin wrote:
> > On Thu, May 17, 2018 at 02:40:06PM +0200, Sebastian Andrzej Siewior wrote:
> > > In v4.16-RT I noticed a number of warnings from task_fpsimd_load
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 rea
On Mon, Jun 04, 2018 at 04:57:54PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the kvm tree got a conflict in:
>
> arch/arm64/include/asm/processor.h
>
> between commit:
>
> 94b07c1f8c39 ("arm64: signal: Report signal frame size to userspace via
> auxv")
>
> f
On Tue, May 15, 2018 at 11:39:36AM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 12:06:50PM +0100, Dave Martin wrote:
> > On Mon, May 14, 2018 at 10:46:28AM +0100, Mark Rutland wrote:
> > > In subsequent patches, we'll want to make use of sve_user_enable() and
On Mon, May 14, 2018 at 07:28:11PM +0100, Kees Cook wrote:
> On Mon, May 14, 2018 at 10:14 AM, Dave Martin wrote:
> > [Reviewer note: this is a cross-arch series. To reduce spam, I have
> > tried not to Cc people on patches they aren't likely to care about.
> > The co
On Tue, May 15, 2018 at 05:33:52PM +0100, Mark Rutland wrote:
> On Tue, May 15, 2018 at 01:19:26PM +0100, Dave Martin wrote:
> > On Tue, May 15, 2018 at 11:39:36AM +0100, Mark Rutland wrote:
> > > On Mon, May 14, 2018 at 12:06:50PM +0100, Dave Martin wrote:
> > > >
es 38 and 39 may have been used for
historical purposes, such as an architecture that is no longer
supported. If they have definitely never been used for anything,
they could be removed from the "reserved" list.
Signed-off-by: Dave Martin
Cc: Richard Henderson
Cc: Ivan Kokshaysky
Cc:
On Wed, May 16, 2018 at 11:29:13AM -0400, Rich Felker wrote:
> On Wed, May 16, 2018 at 03:20:47PM +0100, Dave Martin wrote:
> > There are constraints on defining AT_* auxvec tags that are not
> > obvious to the casual maintainer of either the global
> > or the arch-speci
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/asm/fps
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.
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 th
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 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
> +extern void fpsimd_save_and_flush_cpu_state(void);
Nit: You could drop this blank line: these are all "state maintenance"
operations, roughly speaking.
But don't bother unless you respin for some other reason.
[...]
With or without that,
Reviewed-by: Dave Martin
Cheers
---Dave
On Tue, Apr 23, 2019 at 02:57:19PM +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 th
On Wed, Apr 24, 2019 at 11:27:50AM +0530, Amit Daniel Kachhap wrote:
> Hi,
>
> On 4/23/19 9:14 PM, Dave Martin wrote:
> >On Tue, Apr 23, 2019 at 10:12:34AM +0530, Amit Daniel Kachhap wrote:
> >>A per vcpu flag is added to check if pointer authentication is
> >>
On Thu, Apr 25, 2019 at 01:37:40PM +0100, Julien Grall wrote:
> Hi Dave,
>
> On 24/04/2019 14:17, Dave Martin wrote:
> >On Tue, Apr 23, 2019 at 02:57:18PM +0100, Julien Grall wrote:
> >>tent-Length: 4295
> >>Lines: 128
> >>
> >>The only extern
On Thu, Apr 25, 2019 at 04:57:26PM +0100, Julien Grall wrote:
> Hi Dave,
>
> On 24/04/2019 14:17, Dave Martin wrote:
> >On Tue, Apr 23, 2019 at 02:57:19PM +0100, Julien Grall wrote:
> >>diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> >>
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 kerne
this
> generic definition.
>
> Signed-off-by: Chang S. Bae
> Reviewed-by: Len Brown
> Cc: Carlos O'Donell
> Cc: Dave Martin
> Cc: libc-al...@sourceware.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
On Thu, Feb 04, 2021 at 03:23:34PM +, Will Deacon wrote:
> On Mon, Feb 01, 2021 at 11:40:10AM -0800, Andrei Vagin wrote:
> > ip/r12 for AArch32 and x7 for AArch64 is used to indicate whether or not
> > the stop has been signalled from syscall entry or syscall exit. This
> > means that:
> >
> >
On Sun, May 31, 2020 at 12:13:18PM -0400, Keno Fischer wrote:
> > Keno -- are you planning to send out a patch? You previously spoke about
> > implementing this using PTRACE_SETOPTIONS.
>
> Yes, I'll have a patch for you. Though I've come to the conclusion
> that introducing a new regset is probab
On Sun, May 31, 2020 at 12:20:51PM -0400, Keno Fischer wrote:
> > Can't PTRACE_SYSEMU be emulated by using PTRACE_SYSCALL, cancelling the
> > syscall at the syscall enter stop, then modifying the regs at the
> > syscall exit stop?
>
> Yes, it can. The idea behind SYSEMU is to be able to save half
On Mon, Jun 01, 2020 at 05:23:01AM -0400, Keno Fischer wrote:
> On Mon, Jun 1, 2020 at 5:14 AM Dave Martin wrote:
> > Can you explain why userspace would write a changed value for x7
> > but at the same time need that new to be thrown away?
>
> The discarding behavior
On Mon, Jun 01, 2020 at 05:40:28AM -0400, Keno Fischer wrote:
> On Mon, Jun 1, 2020 at 5:23 AM Dave Martin wrote:
> > > > Can't PTRACE_SYSEMU be emulated by using PTRACE_SYSCALL, cancelling the
> > > > syscall at the syscall enter stop, then modifying the regs
On Fri, Dec 18, 2020 at 06:01:05PM +0100, Ard Biesheuvel wrote:
> Kernel mode NEON can be used in task or softirq context, but only in
> a non-nesting manner, i.e., softirq context is only permitted if the
> interrupt was not taken at a point where the kernel was using the NEON
> in task context.
>
On Tue, Jan 19, 2021 at 05:29:05PM +0100, Ard Biesheuvel wrote:
> On Tue, 19 Jan 2021 at 17:01, Dave Martin wrote:
> >
> > On Fri, Dec 18, 2020 at 06:01:05PM +0100, Ard Biesheuvel wrote:
> > > Kernel mode NEON can be used in task or softirq context, but only in
> &g
On Tue, Jan 19, 2021 at 02:06:36PM -0800, Andrei Vagin wrote:
> This is an alternative to NT_PRSTATUS that clobbers ip/r12 on AArch32,
> x7 on AArch64 when a tracee is stopped in syscall entry or syscall exit
> traps.
>
> Signed-off-by: Andrei Vagin
This approach looks like it works, though I st
On Tue, Jan 19, 2021 at 02:06:35PM -0800, Andrei Vagin wrote:
> ip/r12 for AArch32 and x7 for AArch64 is used to indicate whether or not
> the stop has been signalled from syscall entry or syscall exit. This
> means that:
>
> - Any writes by the tracer to this register during the stop are
> igno
On Thu, Nov 07, 2013 at 06:17:35PM +0100, Ard Biesheuvel wrote:
> This patch implements a generic modalias 'cpu:feature:...' which
> enables CPU feature flag based module loading in a generic way.
> All the arch needs to do is enable CONFIG_ARCH_HAS_CPU_AUTOPROBE
> and export a u32 called 'cpu_feat
On Thu, Nov 07, 2013 at 10:16:13AM -0800, Andy Lutomirski wrote:
> On Thu, Nov 7, 2013 at 9:47 AM, Kees Cook wrote:
> > Make sure that seccomp filter won't be built when ARM OABI is in use,
> > since there is work needed to distinguish calling conventions. Until
> > that is done (which is likely n
On Mon, Feb 10, 2014 at 04:37:00PM +, Russell King - ARM Linux wrote:
> On Mon, Feb 10, 2014 at 04:28:22PM +0000, Dave Martin wrote:
> > On Mon, Feb 10, 2014 at 03:19:34PM +, Russell King - ARM Linux wrote:
> > > On Mon, Feb 10, 2014 at 02:42:28PM +, Dave Martin wro
On Mon, Feb 10, 2014 at 04:38:09PM +, Ben Dooks wrote:
> On 10/02/14 15:21, Dave Martin wrote:
[...]
> >Does PCI have any way of finding out which parts of the configuration
> >space are there before you are forced to go poking around in invalid
> >address space?
>
On Tue, Feb 11, 2014 at 05:56:51PM +, Mark Rutland wrote:
> On Mon, Feb 10, 2014 at 06:10:26PM +, Peter Zijlstra wrote:
> > On Mon, Feb 10, 2014 at 05:44:24PM +, Mark Rutland wrote:
> > > Currently portions of the perf subsystem assume that a
> > > perf_event_context is associated with
On Tue, Feb 18, 2014 at 10:10:03AM -0800, Kees Cook wrote:
> On Mon, Feb 17, 2014 at 4:34 AM, Dave Martin wrote:
> > On Fri, Feb 14, 2014 at 11:11:07AM -0800, Kees Cook wrote:
> >> On Fri, Feb 14, 2014 at 8:22 AM, Dave Martin wrote:
> >> > On Thu, Feb 13, 2014
On Sat, Dec 14, 2013 at 03:47:49PM +0530, Anurag Aggarwal wrote:
> >You could try adding some debug printks to see how the backtrace fails.
> >You could also try adding a few hand-crafted assembler functions
> >with appropriate code and unwind directives to trigger different kinds
> >of backtrace f
On Tue, Jan 07, 2014 at 03:48:25PM +, Arnd Bergmann wrote:
> On Tuesday 07 January 2014 14:41:30 Russell King - ARM Linux wrote:
> > On Tue, Jan 07, 2014 at 03:33:34PM +0100, Arnd Bergmann wrote:
> > >
> > >
> > > It's been almost a year since we last discussed the patches that were
> > > pos
On Tue, Nov 26, 2013 at 12:58:08PM +0400, Vyacheslav Tyrtov wrote:
> From: Tarek Dakhran
>
> Add EDCS(Exynos Dual Cluster Support) for Samsung Exynos5410 SoC.
> This enables all 8 cores, 4 x A7 and 4 x A15 run at the same time.
>
> Signed-off-by: Tarek Dakhran
> Signed-off-by: Vyacheslav Tyrtov
On Tue, Nov 26, 2013 at 10:35:58AM +0900, Alexandre Courbot wrote:
> On Tue, Nov 26, 2013 at 9:06 AM, Olof Johansson wrote:
> > On Sun, Nov 24, 2013 at 03:30:52PM +0900, Alexandre Courbot wrote:
> >> Support for Trusted Foundations is light and allows the kernel to run on
> >> a wider range of dev
On Thu, Nov 28, 2013 at 04:58:33PM +, Stephen Warren wrote:
> On 11/27/2013 11:02 PM, Alexandre Courbot wrote:
> > On Wed, Nov 27, 2013 at 1:47 AM, Dave Martin wrote:
> >> On Tue, Nov 26, 2013 at 10:35:58AM +0900, Alexandre Courbot wrote:
> >>> On Tue, Nov 26, 2
On Thu, Nov 28, 2013 at 03:57:19PM +0530, Anurag Aggarwal wrote:
> While executing some unwind instructions stack overflow can cause a data abort
> when area beyond stack is not mapped to physical memory.
>
> To prevent the data abort check whether it is possible to execute
> these instructions be
Looks like you still need to move your S-o-B line. It needs to be at
the end of the commit message.
On Fri, Nov 29, 2013 at 09:34:31AM +, Anurag Aggarwal wrote:
> While unwinding backtrace, stack overflow is possible. This stack overflow
> can sometimes
> lead to data abort in system if the
On Wed, Nov 06, 2013 at 03:20:48PM +0530, Anurag Aggarwal wrote:
> Altough stack overflow is expected in unwind_exec_insn, but in cases when
> area beyond stack is not mapped to physical memory this can cause data abort.
>
> To avoid above condition handle stack overflow in unwind_exec_insn by
applies the necessary
> relocations to the loaded code. Because the relocations are just relative
> offsets to pointers, the relocations can be reapplied to allow the code
> to run with the MMU enabled or disabled.
>
> This patchset is a complete rethinking of an earlier patchset [1
On Fri, Nov 01, 2013 at 03:08:49PM -0700, Stephen Boyd wrote:
> From: Rohit Vaswani
>
> According to the ePAPR CPUs should have an enable method. On ARM
> the enable-method property has not been used so far, so document
> this property as an optional property and add the spin-table
> method as on
On Mon, Oct 14, 2013 at 03:52:27PM +0530, Majunath Goudar wrote:
> This patch adds a inline dummy implementations of_find_matching_node()
> in "#ifdef CONFIG_OF" else part. Without this patch,build system can
> lead to issues. This was discovered during randconfig testing,in which
> ARM_CCI was ena
201 - 300 of 664 matches
Mail list logo
