On Mon, Apr 15, 2024 at 09:52:41AM +0200, Peter Zijlstra wrote:
> On Thu, Apr 11, 2024 at 07:00:41PM +0300, Mike Rapoport wrote:
> > +/**
> > + * enum execmem_type - types of executable memory ranges
> > + *
> > + * There are several subsystems that allocate executable memory.
> > + *
On Tue, Mar 26, 2024 at 09:15:14AM -0700, Calvin Owens wrote:
> On Wednesday 03/27 at 00:24 +0900, Masami Hiramatsu wrote:
> > On Tue, 26 Mar 2024 14:46:10 +
> > Mark Rutland wrote:
> > > Different exectuable allocations can have different requirements. For
>
On Wed, Mar 27, 2024 at 12:24:03AM +0900, Masami Hiramatsu wrote:
> On Tue, 26 Mar 2024 14:46:10 +
> Mark Rutland wrote:
> >
> > On Mon, Mar 25, 2024 at 11:56:32AM +0900, Masami Hiramatsu wrote:
> > > I think, we'd better to introduce `alloc_execmem()`,
>
Hi Masami,
On Mon, Mar 25, 2024 at 11:56:32AM +0900, Masami Hiramatsu wrote:
> Hi Jarkko,
>
> On Sun, 24 Mar 2024 01:29:08 +0200
> Jarkko Sakkinen wrote:
>
> > Tracing with kprobes while running a monolithic kernel is currently
> > impossible due the kernel module allocator dependency.
> >
>
On Thu, Mar 14, 2024 at 04:07:33PM +0100, Bj"orn T"opel wrote:
> After reading Mark's reply, and discussing with OpenJDK folks (who does
> the most crazy text patching on all platforms), having to patch multiple
> instructions (where the address materialization is split over multiple
>
Hi Bjorn
(apologies, my corporate mail server has butchered your name here).
There's a big info dump below; I realise this sounds like a sales pitch for
CALL_OPS, but my intent is more to say "here are some dragons you may not have
spotted".
On Thu, Mar 07, 2024 at 08:27:40PM +0100, Bj"orn
[adding Valentin]
On Mon, Feb 05, 2024 at 08:06:09AM -0500, Steven Rostedt wrote:
> On Mon, 5 Feb 2024 10:28:57 +
> Mark Rutland wrote:
>
> > > I try to write below:
> > > echo 'target_cpus == 11 && reason == "Function call interrup
On Mon, Feb 05, 2024 at 05:57:29PM +0800, richard clark wrote:
> Hi guys,
>
> With the ipi_raise event enabled and filtered with:
> echo 'reason == "Function call interrupts"' > filter, then the 'cat
> trace' output below messages:
> ...
> insmod-3355[010] 1.. 24479.230381: ipi_raise:
>
; On Mon, 8 Jan 2024 12:25:55 +
> Mark Rutland wrote:
>
> > Hi,
> >
> > There's a bit more of an info-dump below; I'll go try to dump the fgraph
> > shadow
> > stack so that we can analyse this in more detail.
> >
> > On Mon, Jan 08, 2024 at 10:
ys/kernel/tracing/trace
...
-0 [007] ..s3. 172.932840: wake_up_process
<-process_timeout
-0 [007] ..s1. 172.932842: my_direct_func: waking up
kcompactd0-62
-0 [007] ..s3. 173.444836: wake_up_process
<-process_timeout
-0
On Mon, Jan 08, 2024 at 02:21:03PM +, Mark Rutland wrote:
> On Mon, Jan 08, 2024 at 12:25:55PM +0000, Mark Rutland wrote:
> > We also have HAVE_FUNCTION_GRAPH_RET_ADDR_PTR, but since the return address
> > is
> > not on the stack at the point function-entry is inte
On Mon, Jan 08, 2024 at 12:25:55PM +, Mark Rutland wrote:
> We also have HAVE_FUNCTION_GRAPH_RET_ADDR_PTR, but since the return address is
> not on the stack at the point function-entry is intercepted we use the FP as
> the retp value -- in the absence of tail calls this will be
Hi,
There's a bit more of an info-dump below; I'll go try to dump the fgraph shadow
stack so that we can analyse this in more detail.
On Mon, Jan 08, 2024 at 10:14:36AM +0900, Masami Hiramatsu wrote:
> On Fri, 5 Jan 2024 17:09:10 +
> Mark Rutland wrote:
>
> > On Mon, Dec 18
On Mon, Dec 18, 2023 at 10:15:59PM +0900, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google)
>
> Rename ftrace_regs_return_value to ftrace_regs_get_return_value as same as
> other ftrace_regs_get/set_* APIs.
>
> Signed-off-by: Masami Hiramatsu (Google)
Acke
u (Google)
Acked-by: Mark Rutland
Mark.
> ---
> Changes in v3:
> - Add instruction pointer
> Changes in v2:
> - newly added.
> ---
> include/linux/ftrace.h | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/include
On Mon, Dec 18, 2023 at 10:13:46PM +0900, Masami Hiramatsu (Google) wrote:
> From: Steven Rostedt (VMware)
>
> Allow for instances to have their own ftrace_ops part of the fgraph_ops
> that makes the funtion_graph tracer filter on the set_ftrace_filter file
> of the instance and not the top
On Thu, Dec 14, 2023 at 02:49:29PM -0600, Madhavan T. Venkataraman wrote:
> Hi Mark,
Hi Madhavan,
> I attended your presentation in the LPC. You mentioned that you could use
> some help with some pre-requisites for the Livepatch feature.
> I would like to lend a hand.
Cool!
I've been meaning
On Wed, Nov 22, 2023 at 10:12:51AM -0500, Steven Rostedt wrote:
> On Wed, 22 Nov 2023 19:49:43 +0530
> Naresh Kamboju wrote:
>
> > Hi Steven,
> >
> >
> >
> > On Tue, 21 Nov 2023 at 02:06, Steven Rostedt wrote:
> > >
> > > On Thu, 16 Nov 2023 18:00:16 +0530
> > > Naresh Kamboju wrote:
> > [
On Sun, Nov 12, 2023 at 11:00:30PM +0800, Kairui Song wrote:
> From: Kairui Song
>
> Following kernel panic was observed when doing ftrace stress test:
Can you share some more details:
* What test specifically are you running? Can you share this so that others can
try to reproduce the issue?
On Thu, Nov 09, 2023 at 08:14:52AM +0900, Masami Hiramatsu wrote:
> On Wed, 8 Nov 2023 23:24:32 +0900
> "Masami Hiramatsu (Google)" wrote:
>
> > From: Masami Hiramatsu (Google)
> >
> > To clarify what will be expected on ftrace_regs, add a comment to the
> > architecture independent
On Wed, Oct 25, 2023 at 08:42:55AM +0900, Masami Hiramatsu wrote:
> On Tue, 24 Oct 2023 16:08:12 +0100
> Mark Rutland wrote:
>
> > On Tue, Oct 24, 2023 at 11:52:54PM +0900, Masami Hiramatsu (Google) wrote:
> > > From: Masami Hiramatsu (Google)
> > >
On Tue, Oct 24, 2023 at 11:52:54PM +0900, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google)
>
> Use generic_cmpxchg_local() for arch_cmpxchg_local() implementation
> in SH architecture because it does not implement arch_cmpxchg_local().
I do not think this is correct.
The
licitly truncated to compat_ulong_t, and
audit expects the non-truncated return value. Other architectures don't
truncate here, so I think we're setting ourselves up for a game of
whack-a-mole to truncate and extend wherever we need to.
Given that, I suspect it'd be better to do something like the below.
Will, thoughts?
On Wed, Apr 14, 2021 at 01:28:16PM +0200, Marco Elver wrote:
> This series adds support for showing observed value changes in reports.
> Several clean up and refactors of KCSAN reporting code are done as a
> pre-requisite.
> This series was originally prepared courtesy of
On Fri, Apr 09, 2021 at 03:32:47PM +0100, Mark Rutland wrote:
> Hi Vincenzo,
>
> On Fri, Apr 09, 2021 at 02:24:19PM +0100, Vincenzo Frascino wrote:
> > The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
> > race with another CPU doing a set_tsk_
Hi Vincenzo,
On Fri, Apr 09, 2021 at 02:24:19PM +0100, Vincenzo Frascino wrote:
> The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
> race with another CPU doing a set_tsk_thread_flag() and all the other flags
> can be lost in the process.
>
> Move the tcf0 check to
On Mon, Apr 05, 2021 at 03:43:12PM -0500, madve...@linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman"
>
> When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled and tracing is activated
> for a function, the ftrace infrastructure is called for the function at
> the very beginning. Ftrace
Hi Madhavan,
I've noted some concerns below. At a high-level, I'm not keen on the
blacklisting approach, and I think there's some other preparatory work
that would be more valuable in the short term.
On Mon, Apr 05, 2021 at 03:43:09PM -0500, madve...@linux.microsoft.com wrote:
> From: "Madhavan
Hi Vincenzo,
On Thu, Apr 08, 2021 at 03:37:23PM +0100, Vincenzo Frascino wrote:
> The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
> race with another CPU doing a set_tsk_thread_flag() and the flag can be
> lost in the process.
>
> Move the tcf0 check to
On Thu, Apr 08, 2021 at 03:56:04PM +0100, Will Deacon wrote:
> On Thu, Apr 08, 2021 at 03:37:23PM +0100, Vincenzo Frascino wrote:
> > The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
> > race with another CPU doing a set_tsk_thread_flag() and the flag can be
> > lost in the
On Wed, Apr 07, 2021 at 01:44:37PM +0100, Will Deacon wrote:
> [Moving Mark to To: since I'd like his view on this]
>
> On Thu, Apr 01, 2021 at 02:45:21PM -0500, Rob Herring wrote:
> > On Wed, Mar 31, 2021 at 11:01 AM Will Deacon wrote:
> > >
> > > On Tue, Mar 30, 2021 at 12:09:38PM -0500, Rob
; + pc = (unsigned long)function_nocfi(ftrace_call);
Acked-by: Mark Rutland
Thanks,
Mark.
> new = aarch64_insn_gen_branch_imm(pc, (unsigned long)func,
> AARCH64_INSN_BRANCH_LINK);
>
> --
> 2.31.0.208.g409f899ff0-goog
>
[adding Ard for EFI runtime services bits]
On Thu, Apr 01, 2021 at 04:32:12PM -0700, Sami Tolvanen wrote:
> Disable CFI checking for functions that switch to linear mapping and
> make an indirect call to a physical address, since the compiler only
> understands virtual addresses and the CFI check
_relaxed(__pa_symbol(secondary_holding_pen), release_addr);
> + writeq_relaxed(__pa_symbol(function_nocfi(secondary_holding_pen)),
> +release_addr);
Likewise here? e.g. at the start of the function have:
phys_addr_t pa_holding_pen =
__pa_symbol(function_nocfi(secondary_holding_pen));
... then here have:
writeq_relaxed(pa_holding_pen, release_addr);
With those:
Acked-by: Mark Rutland
Thanks,
Mark.
> __flush_dcache_area((__force void *)release_addr,
> sizeof(*release_addr));
>
> --
> 2.31.0.208.g409f899ff0-goog
>
>
> Signed-off-by: Sami Tolvanen
> Reviewed-by: Kees Cook
I think that it's unfortunate that we have to drop to assembly here, but
given this is infrequent I agree it's not the end of the world, so:
Acked-by: Mark Rutland
> ---
> arch/arm64/include/asm/memory.h | 15 ++
mediate jump to an EL1 virtual address, this typically won't
> work as intended. Use function_nocfi to get the actual address of
> cpu_resume.
>
> Signed-off-by: Sami Tolvanen
> Reviewed-by: Kees Cook
Acked-by: Mark Rutland
Mark.
> ---
> drivers/firmware/psci/psci.c | 7 +-
> can override. The typical implementation of would use inline assembly
> to take the function address, which avoids compiler instrumentation.
>
> Signed-off-by: Sami Tolvanen
> Reviewed-by: Kees Cook
FWIW:
Acked-by: Mark Rutland
Mark.
> ---
> include/linux/mm.h | 10
Hi Madhavan,
Overall this looks pretty good; I have a few comments below.
On Wed, Mar 24, 2021 at 01:46:07PM -0500, madve...@linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman"
>
> The unwinder needs to be able to reliably tell when it has reached the end
> of a stack trace. One way
On Tue, Mar 23, 2021 at 01:39:41PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler replaces function addresses in
> instrumented C code with jump table addresses. This change implements
> the __va_function() macro, which returns the actual function address
> instead.
>
>
On Tue, Mar 23, 2021 at 01:39:40PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler replaces function pointers with
> jump table addresses, which results in __pa_symbol returning the
> physical address of the jump table entry. As the jump table contains
> an immediate jump to an
On Wed, Mar 24, 2021 at 08:54:18AM -0700, Sami Tolvanen wrote:
> On Wed, Mar 24, 2021 at 12:14 AM Christoph Hellwig wrote:
> >
> > On Tue, Mar 23, 2021 at 01:39:32PM -0700, Sami Tolvanen wrote:
> > > With CONFIG_CFI_CLANG, the compiler replaces function addresses
> > > in instrumented C code with
On Thu, Mar 25, 2021 at 04:55:51AM +, Michael Kelley wrote:
> From: Mark Rutland Sent: Wednesday, March 24, 2021
> 9:55 AM
> > For the benefit of others here, SMCCCv1.2 allows:
> >
> > * SMC64/HVC64 to use all of x1-x17 for both parameters and return values
>
On Wed, Mar 24, 2021 at 06:38:18PM +, Will Deacon wrote:
> On Fri, Mar 05, 2021 at 06:38:48AM +0900, Hector Martin wrote:
> > Apple ARM64 SoCs have a ton of vendor-specific registers we're going to
> > have to deal with, and those don't really belong in sysreg.h with all
> > the architectural
Hi Michael,
On Mon, Mar 08, 2021 at 11:57:13AM -0800, Michael Kelley wrote:
> Hypercalls to Hyper-V on ARM64 may return results in registers other
> than X0 thru X3, as permitted by the SMCCC spec version 1.2 and later.
> Accommodate this by adding a variant of arm_smccc_1_1_hvc that allows
> the
Hi,
On Wed, Mar 24, 2021 at 12:24:59PM +0530, Maninder Singh wrote:
> In case of a use after free kernel OOPs, freed path of the object is
> required to debug futher. In most of cases the object address is present
> in one of the registers.
>
> Thus check the register's address and if it belongs
On Tue, Mar 23, 2021 at 12:23:34PM -0500, Madhavan T. Venkataraman wrote:
> On 3/23/21 12:02 PM, Mark Rutland wrote:
[...]
> I think that I did a bad job of explaining what I wanted to do. It is not
> for any additional protection at all.
>
> So, let us say we create a fi
On Tue, Mar 23, 2021 at 11:53:04AM -0500, Madhavan T. Venkataraman wrote:
> On 3/23/21 11:48 AM, Mark Rutland wrote:
> > On Tue, Mar 23, 2021 at 10:26:50AM -0500, Madhavan T. Venkataraman wrote:
> >> So, my next question is - can we define a practical limit for the
> >>
On Tue, Mar 23, 2021 at 11:20:44AM -0500, Madhavan T. Venkataraman wrote:
> On 3/23/21 10:26 AM, Madhavan T. Venkataraman wrote:
> > On 3/23/21 9:57 AM, Mark Rutland wrote:
> >> On Tue, Mar 23, 2021 at 09:15:36AM -0500, Madhavan T. Venkataraman wrote:
> > So, my next que
On Tue, Mar 23, 2021 at 10:26:50AM -0500, Madhavan T. Venkataraman wrote:
> On 3/23/21 9:57 AM, Mark Rutland wrote:
> Thanks for explaining the nesting. It is now clear to me.
No problem!
> So, my next question is - can we define a practical limit for the
> nesting so that any ne
On Tue, Mar 23, 2021 at 09:15:36AM -0500, Madhavan T. Venkataraman wrote:
> Hi Mark,
>
> I have a general question. When exceptions are nested, how does it work? Let
> us consider 2 cases:
>
> 1. Exception in a page fault handler itself. In this case, I guess one more
> pt_regs will get
>
On Tue, Mar 23, 2021 at 08:31:50AM -0500, Madhavan T. Venkataraman wrote:
> On 3/23/21 8:04 AM, Mark Rutland wrote:
> > On Tue, Mar 23, 2021 at 07:46:10AM -0500, Madhavan T. Venkataraman wrote:
> >> On 3/23/21 5:42 AM, Mark Rutland wrote:
> >>> On Mon, Mar 15, 2
On Tue, Mar 23, 2021 at 07:56:40AM -0500, Madhavan T. Venkataraman wrote:
>
>
> On 3/23/21 5:51 AM, Mark Rutland wrote:
> > On Mon, Mar 15, 2021 at 11:57:57AM -0500, madve...@linux.microsoft.com
> > wrote:
> >> From: "Madhavan T. Venkataraman"
> &
On Tue, Mar 23, 2021 at 07:46:10AM -0500, Madhavan T. Venkataraman wrote:
> On 3/23/21 5:42 AM, Mark Rutland wrote:
> > On Mon, Mar 15, 2021 at 11:57:56AM -0500, madve...@linux.microsoft.com
> > wrote:
> >> From: "Madhavan T. Venkataraman"
> >>
> &
On Mon, Mar 15, 2021 at 11:57:57AM -0500, madve...@linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman"
>
> When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled and tracing is activated
> for a function, the ftrace infrastructure is called for the function at
> the very beginning. Ftrace
On Mon, Mar 15, 2021 at 11:57:56AM -0500, madve...@linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman"
>
> EL1 exceptions can happen on any instruction including instructions in
> the frame pointer prolog or epilog. Depending on where exactly they happen,
> they could render the stack
On Thu, Mar 18, 2021 at 03:29:19PM -0500, Madhavan T. Venkataraman wrote:
>
>
> On 3/18/21 1:26 PM, Mark Brown wrote:
> > On Mon, Mar 15, 2021 at 11:57:55AM -0500, madve...@linux.microsoft.com
> > wrote:
> >
> >> + /* Terminal record, nothing to unwind */
> >> + if (fp == (unsigned long)
On Mon, Mar 15, 2021 at 11:57:54AM -0500, madve...@linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman"
>
> Apart from the task pt_regs, pt_regs is also created on the stack for other
> other cases:
>
> - EL1 exception. A pt_regs is created on the stack to save register
>
On Fri, Mar 19, 2021 at 05:03:09PM -0500, Madhavan T. Venkataraman wrote:
> I solved this by using existing functions logically instead of inventing a
> dummy function. I initialize pt_regs->stackframe[1] to an existing function
> so that the stack trace will not show a 0x0 entry as well as the
Hi Russell,
On Fri, Mar 19, 2021 at 10:10:43AM +, Russell King - ARM Linux admin wrote:
> On Fri, Mar 19, 2021 at 10:54:48AM +0100, Dmitry Vyukov wrote:
> > .On Fri, Mar 19, 2021 at 10:44 AM syzbot
> > wrote:
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:8b12a62a
On Fri, Mar 19, 2021 at 07:02:06PM +, Catalin Marinas wrote:
> On Fri, Mar 19, 2021 at 06:41:06PM +0000, Mark Rutland wrote:
> > We recently converted arm64 to use arch_stack_walk() in commit:
> >
> > 5fc57df2f6fd ("arm64: stacktrace: Convert to ARCH_STACKWALK"
Hi Christoph,
On Mon, Mar 15, 2021 at 07:28:03PM +, Christoph Hellwig wrote:
> On Mon, Mar 15, 2021 at 11:56:25AM +0000, Mark Rutland wrote:
> > From: Marc Zyngier
> >
> > In subsequent patches we want to allow irqchip drivers to register as
> > FIQ hand
and checking that
the assembly looked sound. For GCC (where we require version 5.1.0 or
later) I tested with the kernel.org crosstool binares for versions
5.5.0, 6.4.0, 6.5.0, 7.3.0, 7.5.0, 8.1.0, 8.3.0, 8.4.0, 9.2.0, and
10.1.0. For clang (where we require version 10.0.1 or later) I tested
with th
On Thu, Mar 18, 2021 at 04:17:24PM +, Catalin Marinas wrote:
> On Wed, Mar 17, 2021 at 07:34:16PM +0000, Mark Rutland wrote:
> > On Wed, Mar 17, 2021 at 06:36:36PM +, Catalin Marinas wrote:
> > > On Wed, Mar 17, 2021 at 02:20:50PM +, Chen Jun wrote:
> > >
On Wed, Mar 17, 2021 at 06:36:36PM +, Catalin Marinas wrote:
> On Wed, Mar 17, 2021 at 02:20:50PM +, Chen Jun wrote:
> > On ARM64, cat /sys/kernel/debug/page_owner, all pages return the same
> > stack:
> > stack_trace_save+0x4c/0x78
> > register_early_stack+0x34/0x70
> >
On Thu, Mar 11, 2021 at 05:56:46PM +0100, Dmitry Vyukov wrote:
> On Thu, Mar 11, 2021 at 1:33 PM Mark Rutland wrote:
> > FWIW, I keep my fuzzing config fragment in my fuzzing/* branches on
> > git.kernel.org, and for comparison my fragment for v5.12-rc1 is:
> >
> > htt
to the macros.
There should be no functional change as a result of this patch.
Signed-off-by: Marc Zyngier
[Mark: rework macros, commit message, rebase before DAIF rework]
Signed-off-by: Mark Rutland
Tested-by: Hector Martin
Cc: Catalin Marinas
Cc: James Morse
Cc: Thomas Gleixner
Cc: Will Deacon
is deferred to that handler.
As el0_fiq_invalid_compat is supplanted by el0_fiq, the former is
removed. For !CONFIG_COMPAT builds we never expect to take an exception
from AArch32 EL0, so we keep the common el0_fiq_invalid handler.
Signed-off-by: Mark Rutland
Tested-by: Hector Martin
Cc: Catalin
-off-by: Hector Martin
Signed-off-by: Mark Rutland
Tested-by: Hector Martin
Cc: Catalin Marinas
Cc: James Morse
Cc: Marc Zyngier
Cc: Thomas Gleixner
Cc: Will Deacon
---
arch/arm64/include/asm/arch_gicv3.h | 2 +-
arch/arm64/include/asm/assembler.h | 8
arch/arm64/include/asm
logic similar, this patch removes the panic in the absence of a root IRQ
controller. Instead, set_handle_irq() logs when a handler is registered,
which is sufficient for debug purposes.
Signed-off-by: Mark Rutland
Tested-by: Hector Martin
Cc: Catalin Marinas
Cc: James Morse
Cc: Marc Zyngier
Cc
by allowing architectures to provide their own
implementation of set_handle_irq when CONFIG_GENERIC_IRQ_MULTI_HANDLER
is not selected.
Signed-off-by: Marc Zyngier
[Mark: expand commit message]
Signed-off-by: Mark Rutland
Tested-by: Hector Martin
Cc: Catalin Marinas
Cc: James Morse
Cc: Thomas
for the
former.
This patch adds an arm64-specific implementation of set_handle_irq().
There should be no functional change as a result of this patch.
Signed-off-by: Marc Zyngier
[Mark: use a single handler pointer]
Signed-off-by: Mark Rutland
Tested-by: Hector Martin
Cc: Catalin Marinas
Cc: James Morse
rride set_handle_irq() fallback
arm64: don't use GENERIC_IRQ_MULTI_HANDLER
arm64: entry: factor irq triage logic into macros
Mark Rutland (2):
arm64: irq: rework root IRQ handler registration
arm64: irq: allow FIQs to be handled
arch/arm64/Kconfig | 1 -
arch/arm64/incl
On Thu, Mar 11, 2021 at 12:38:21PM +0100, 'Dmitry Vyukov' via syzkaller wrote:
> Hi arm64 maintainers,
Hi Dmitry,
> We now have some syzbot instances testing arm64 (woohoo!) using qemu
> emulation. I wanted to write up the current status.
Nice!
> There are 3 instances, first uses KASAN:
>
On Tue, Mar 09, 2021 at 04:05:32PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Mar 09, 2021 at 04:05:23PM +0000, Mark Rutland wrote:
> > On Thu, Mar 04, 2021 at 03:54:48PM -0600, Segher Boessenkool wrote:
> > > On Thu, Mar 04, 2021 at 02:57:30PM +, Mark Rutland
bb75953, this does appear to be the only
point of truncation given read_pmevcntrn() directly returns the result
of read_sysreg(), so:
Acked-by: Mark Rutland
Will, could you pick this up?
Thanks,
Mark.
> Fixes: 0fdf1bb75953 ("arm64: perf: Avoid PMXEV* indirection")
> Cc: Ale
On Thu, Mar 04, 2021 at 03:54:48PM -0600, Segher Boessenkool wrote:
> Hi!
Hi Segher,
> On Thu, Mar 04, 2021 at 02:57:30PM +, Mark Rutland wrote:
> > It looks like GCC is happy to give us the function-entry-time FP if we use
> > __builtin_frame_address(1),
>
On Mon, Mar 08, 2021 at 04:14:31PM +, Vincenzo Frascino wrote:
> load_unaligned_zeropad() and __get/put_kernel_nofault() functions can
> read passed some buffer limits which may include some MTE granule with a
> different tag.
s/passed/past/
> When MTE async mode is enable, the load
On Fri, Mar 05, 2021 at 07:08:50PM +0900, Hector Martin wrote:
> On 02/03/2021 19.12, Mark Rutland wrote:
> > I'm hoping that we can get the first 2 patches in as a preparatory cleanup
> > for
> > the next rc or so, and then the rest of the series can be rebased atop
On Mon, Mar 08, 2021 at 01:30:53PM +, Will Deacon wrote:
> On Sun, Mar 07, 2021 at 05:24:21PM +0530, Anshuman Khandual wrote:
> > On 3/5/21 8:21 PM, Mark Rutland wrote:
> > > On Fri, Mar 05, 2021 at 08:06:09PM +0530, Anshuman Khandual wrote
On Thu, Mar 04, 2021 at 11:06:01AM -0800, Andy Lutomirski wrote:
> In principle, the generic entry code is generic, and the goal is to use it
> in many architectures once it settles down more. Move CONFIG_DEBUG_ENTRY
> to the generic config so that it can be used in the generic entry code and
>
On Thu, Mar 04, 2021 at 11:06:00AM -0800, Andy Lutomirski wrote:
> exit_to_user_mode() does part, but not all, of the exit-to-user-mode work.
> It's used only by arm64, and arm64 should stop using it (hint, hint!).
> Compile it out on other architectures to minimize the chance of error.
For
er to use
> right, and the diffstat should speak for itself.
>
> Signed-off-by: Andy Lutomirski
I think that having this more verbose is going to make it easier to
handle ABI warts that differ across architectures, so:
Acked-by: Mark Rutland
Mark.
> ---
> arch/x86/
y
> entry to the kernel.
>
> This path doesn't touch the .irqentry section -- someone can contemplate
> changing that later. That code predates the common entry code.
>
> Signed-off-by: Andy Lutomirski
FWIW, I agree this is a better name, so:
Acked-by: Mark Rutland
Mark.
>
ilar situations in EFI stub and KVM as well.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Marc Zyngier
> Cc: James Morse
> Cc: Suzuki K Poulose
> Cc: Ard Biesheuvel
> Cc: Mark Rutland
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: kvm...@lists.cs.columb
On Thu, Mar 04, 2021 at 08:01:29PM +0100, Marco Elver wrote:
> On Thu, 4 Mar 2021 at 19:51, Mark Rutland wrote:
> > On Thu, Mar 04, 2021 at 07:22:53PM +0100, Marco Elver wrote:
> > > I was having this problem with KCSAN, where the compiler would
> > > tail-call-optimi
On Thu, Mar 04, 2021 at 07:22:53PM +0100, Marco Elver wrote:
> On Thu, 4 Mar 2021 at 19:02, Mark Rutland wrote:
> > On Thu, Mar 04, 2021 at 06:25:33PM +0100, Marco Elver wrote:
> > > On Thu, Mar 04, 2021 at 04:59PM +, Mark Rutland wrote:
> > > > On Thu, Mar 04, 2
On Thu, Mar 04, 2021 at 06:25:33PM +0100, Marco Elver wrote:
> On Thu, Mar 04, 2021 at 04:59PM +0000, Mark Rutland wrote:
> > On Thu, Mar 04, 2021 at 04:30:34PM +0100, Marco Elver wrote:
> > > On Thu, 4 Mar 2021 at 15:57, Mark Rutland wrote:
> > > > [adding Mark Bro
On Thu, Mar 04, 2021 at 04:30:34PM +0100, Marco Elver wrote:
> On Thu, 4 Mar 2021 at 15:57, Mark Rutland wrote:
> > [adding Mark Brown]
> >
> > The bigger problem here is that skipping is dodgy to begin with, and
> > this is still liable to break in
[adding Mark Brown]
On Wed, Mar 03, 2021 at 04:20:43PM +0100, Marco Elver wrote:
> On Wed, Mar 03, 2021 at 03:52PM +0100, Christophe Leroy wrote:
> > Le 03/03/2021 � 15:38, Marco Elver a �crit�:
> > > On Wed, 3 Mar 2021 at 15:09, Christophe Leroy
> > > wrote:
> > > >
> > > > It seems like
is deferred to that handler.
As el0_fiq_invalid_compat is supplanted by el0_fiq, the former is
removed. For !CONFIG_COMPAT builds we never expect to take an exception
from AArch32 EL0, so we keep the common el0_fiq_invalid handler.
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc
to the macros.
There should be no functional change as a result of this patch.
Signed-off-by: Marc Zyngier
[Mark: rework macros, commit message, rebase before DAIF rework]
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc: Thomas Gleixner
Cc: Will Deacon
---
arch
-off-by: Hector Martin
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: James Morse
Cc: Marc Zyngier
Cc: Thomas Gleixner
Cc: Will Deacon
---
arch/arm64/include/asm/arch_gicv3.h | 2 +-
arch/arm64/include/asm/assembler.h | 8
arch/arm64/include/asm/daifflags.h | 10
logic similar, this patch removes the panic in the absence of a root IRQ
controller. Instead, set_handle_irq() logs when a handler is registered,
which is sufficient for debug purposes.
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc: Marc Zyngier
Cc: Thomas
k
arm64: don't use GENERIC_IRQ_MULTI_HANDLER
arm64: entry: factor irq triage logic into macros
Mark Rutland (2):
arm64: irq: rework root IRQ handler registration
arm64: irq: allow FIQs to be handled
arch/arm/Kconfig| 1 +
arch/arm64/Kconfig | 1 -
ar
for the
former.
This patch adds an arm64-specific implementation of set_handle_irq().
There should be no functional change as a result of this patch.
Signed-off-by: Marc Zyngier
[Mark: use a single handler pointer]
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc
by allowing architectures to provide their own
implementation of set_handle_irq when CONFIG_GENERIC_IRQ_MULTI_HANDLER
is not selected.
Signed-off-by: Marc Zyngier
[Mark: expand commit message]
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc: Thomas Gleixner
-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20210217142800.2547737-1-...@kernel.org
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc: Thomas Gleixner
Cc: Will Deacon
---
drivers/irqchip/Kconfig | 9 -
1 file changed, 9 deletions(-)
diff
.
Reported-by: Marc Rutland
Signed-off-by: Marc Zyngier
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Hector Martin
Cc: James Morse
Cc: Thomas Gleixner
Cc: Will Deacon
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index
On Wed, Feb 24, 2021 at 01:34:09PM -0600, Madhavan T. Venkataraman wrote:
> On 2/24/21 6:17 AM, Mark Rutland wrote:
> > On Tue, Feb 23, 2021 at 12:12:43PM -0600, madve...@linux.microsoft.com
> > wrote:
> >> From: "Madhavan T. Venka
On Fri, Feb 19, 2021 at 06:10:56PM +, Marc Zyngier wrote:
> Hi Mark,
>
> On Fri, 19 Feb 2021 11:38:56 +0000,
> Mark Rutland wrote:
> >
> > Hector's M1 support series [1] shows that some platforms have critical
> > interrupts wired to FIQ, and to support thes
1 - 100 of 8690 matches
Mail list logo
