On Wed, Jun 11, 2025 at 09:15:10AM +0530, Anshuman Khandual wrote:
>
>
> On 10/06/25 10:31 PM, Marc Zyngier wrote:
> > On Tue, 10 Jun 2025 06:31:28 +0100,
> > Anshuman Khandual wrote:
> >>
> >> Change MDSCR_EL1 register holding local variables as uint64_t that reflects
> >> its true register wid
or
> setting vector lengths and setting SVE_VL_INHERIT in sve-ptrace to
> spuriously fail. Set the flag to avoid the issue, we still support not
> supplying register data.
>
> Signed-off-by: Mark Brown
Acked-by: Mark Rutland
Mark.
> ---
> tools/testing/selftests/arm64/fp/s
; this being supported which was not updated to reflect the new behaviour.
> Fix the test to expect a failure when writing FPSIMD data to the
> streaming mode register set.
>
> Signed-off-by: Mark Brown
Acked-by: Mark Rutland
Mark.
> ---
> tools/testing/selftests/arm64/fp/sv
something equivalent prior to that.
With that fixed:
Acked-by: Mark Rutland
Mark.
> Signed-off-by: Mark Brown
> ---
> tools/testing/selftests/arm64/fp/sve-ptrace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/arm64/fp/
On Fri, May 23, 2025 at 04:27:11PM +0100, Mark Brown wrote:
> Mark Rutland's recent SME fixes updated the SME ABI to reject any
> attempt to write FPSIMD register data via the streaming mode SVE
> register set but did not update the sve-ptrace test to take account of
> this, resulting in spurious f
On Tue, May 20, 2025 at 03:28:45PM +0100, Will Deacon wrote:
> On Mon, May 19, 2025 at 02:41:06PM +0100, Mark Rutland wrote:
> > I've pushed a arm64/stacktrace-updates branch [1] with fixups for those
> > as two separate commits atop this one. If that looks good to you I
>
On Fri, May 16, 2025 at 09:53:36AM -0700, Song Liu wrote:
> ARM folks, please share your thoughts on this work. To fully support
> livepatching of kernel modules, we also need [1]. We hope we can
> land this in the 6.16 kernel.
>
> Thanks,
> Song
>
> [1]
> https://lore.kernel.org/linux-arm-kerne
On Thu, Mar 20, 2025 at 10:15:58AM -0700, Song Liu wrote:
> With proper exception boundary detection, it is possible to implment
> arch_stack_walk_reliable without sframe.
>
> Note that, arch_stack_walk_reliable does not guarantee getting reliable
> stack in all scenarios. Instead, it can reliably
On Fri, May 16, 2025 at 09:53:36AM -0700, Song Liu wrote:
> On Thu, Apr 10, 2025 at 8:17 AM Petr Mladek wrote:
> >
> [...]
> > >
> > > [1]
> > > https://lore.kernel.org/live-patching/20250127213310.2496133-1-wn...@google.com/
> > > [2]
> > > https://lore.kernel.org/live-patching/20250129232936.1
On Thu, Apr 17, 2025 at 12:32:49AM +0100, Mark Brown wrote:
> This test program, originally written by Mark Rutland and lightly modified
> by me for upstream,
For context, I had originally pushed this as a WIP to:
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h
signal
> deliveries. In preparation for using the irritators let's implement them,
> just trivially SMSTOP and SMSTART to reset all bits in the register to 0.
>
> Signed-off-by: Mark Brown
Acked-by: Mark Rutland
Mark.
> ---
> tools/testing/selftests/arm64/fp/za
sting
> kernel mode FP usage provide a handler for SIGUSR1 which just counts the
> number of signals like we do for SIGUSR2, allowing fp-stress to treat all
> the test programs uniformly.
>
> Signed-off-by: Mark Brown
Acked-by: Mark Rutland
Mark.
> ---
> tools/testing/s
;
> Signed-off-by: Mark Brown
Acked-by: Mark Rutland
Mark.
> ---
> tools/testing/selftests/arm64/fp/fp-stress.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/arm64/fp/fp-stress.c
> b/tools/t
On Wed, Oct 23, 2024 at 09:38:30PM +0100, Mark Brown wrote:
> The irritator handlers for the fp-stress test programs all use ADR to load
> an address into x0 which is then not referenced. Remove these ADRs as they
> just cause confusion.
>
> Signed-off-by: Mark Brown
Acked-b
On Wed, Oct 23, 2024 at 09:38:31PM +0100, Mark Brown wrote:
> When building for streaming SVE the irritator for SVE skips updates of both
> P15 and FFR. While FFR is skipped since it might not be present there is no
> reason to skip corrupting P15 so move the ifdef appropriately.
I think you mean
f-by: Mark Brown
Acked-by: Mark Rutland
Mark.
> ---
> tools/testing/selftests/arm64/fp/fpsimd-test.S | 3 +--
> tools/testing/selftests/arm64/fp/sve-test.S| 3 +--
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/selftests/arm64/fp/fpsimd
e signal generation out of the main
> supervisor thread, though we should also consider that he percentage of
> time that we spend interacting with the floating point state is also a
> consideration.
>
> Suggested-by: Mark Rutland
> Signed-off-by: Mark Brown
> ---
> tools
Nit: the title says we lower the poll interval, while we actually raise
it. Maybe that'd be clearer as:
kselftest/arm64: Raise poll timeout while waiting for fp-stress children
... or:
kselftest/arm64: Poll less frequently while waiting for fp-stress
children
That aside, this l
On Wed, Oct 23, 2024 at 09:38:28PM +0100, Mark Brown wrote:
> Currently we test signal delivery to the programs run by fp-stress but
> our signal handlers simply count the number of signals seen and don't do
> anything with the floating point state. The original fpsimd-test and
> sve-test programs
On Wed, Aug 21, 2024 at 04:32:46PM +0100, Mark Rutland wrote:
> On Wed, Aug 21, 2024 at 07:05:39AM +0900, Masami Hiramatsu wrote:
> > On Tue, 20 Aug 2024 08:10:42 -0700
> > Sami Tolvanen wrote:
> >
> > > On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
> >
On Wed, Aug 21, 2024 at 07:05:39AM +0900, Masami Hiramatsu wrote:
> On Tue, 20 Aug 2024 08:10:42 -0700
> Sami Tolvanen wrote:
>
> > On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
> > >
> > > On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
> On Mon, 19 Aug 2024 12:02:44 -0400
> Steven Rostedt wrote:
>
> > On Tue, 20 Aug 2024 00:56:49 +0900
> > Masami Hiramatsu (Google) wrote:
> > >
> > > >
> > > > We may need to add "noinline" or something to make sure those funct
On Wed, Aug 14, 2024 at 08:03:56AM +, Liao Chang wrote:
> As Andrii pointed out, the uprobe/uretprobe selftest bench run into a
> counterintuitive result that nop and push variants are much slower than
> ret variant [0]. The root cause lies in the arch_probe_analyse_insn(),
> which excludes 'no
On Wed, Jun 05, 2024 at 02:03:39PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Describe what ftrace_hash_move() does and add some more comments to some
> other functions to make it easier to understand.
>
> Signed-off-by: Steven Rostedt (Goog
es.
>
> Signed-off-by: Steven Rostedt (Google)
Acked-by: Mark Rutland
Mark.
> ---
> kernel/trace/ftrace.c | 23 ---
> 1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 1a2444199
.
> Remove the "filter_hash" parameter from __filter_hash_rec_update() and
> comment the function for what it really is doing.
>
> Signed-off-by: Steven Rostedt (Google)
FWIW, this looks good to me, and works in testing, so:
Reviewed-by: Mark Rutland
Tested-by: Mark Rutlan
ated one. Rename it to "__move_hash()" (using starting underscores as
> it is an internal function), and add some comments about what it does.
>
> Signed-off-by: Steven Rostedt (Google)
Acked-by: Mark Rutland
Mark.
> ---
> kernel/trace/ftrace.c | 8 ++--
> 1
On Mon, Jun 03, 2024 at 03:07:04PM -0400, Steven Rostedt wrote:
> This is a continuation of the function graph multi user code.
> I wrote a proof of concept back in 2019 of this code[1] and
> Masami started cleaning it up. I started from Masami's work v10
> that can be found here:
>
>
> https://
mentation to what the function does.
>
> Signed-off-by: Steven Rostedt (Google)
Aside from the issue with forward declarations that need to be updated,
this looks good to me, so with that fixed:
Acked-by: Mark Rutland
Mark.
> ---
> kernel/trace/ftrace.c | 33 ++
in true to __ftrace_hash_rec_update().
>
> Also add some comments to both those functions explaining what they do.
>
> Signed-off-by: Steven Rostedt (Google)
Looks good to me.
Acked-by: Mark Rutland
Mark.
> ---
> kernel/trace/ftrace.c | 24
> 1
On Tue, Jun 04, 2024 at 05:28:19PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The function __ftrace_hash_rec_update() parameter "filter_hash" is only
> used for true or false (boolean), but is of type int. It already has an
> "inc" parameter that is boolean. This is confus
it can not
> find them. Without fungraph-proc option set, it will not be displayed and
> the test will fail.
>
> Link: https://lore.kernel.org/all/Zl9JFnzKGuUM10X2@J2N7QTR9R3/
>
> Fixes: 35b944a997e2 ("selftests/ftrace: Add function_graph tracer to
> func-filter-pid test
On Tue, Jun 04, 2024 at 12:31:24PM -0400, Steven Rostedt wrote:
> On Tue, 4 Jun 2024 15:44:40 +0100
> Mark Rutland wrote:
>
> > Hi Steve, Masami,
> >
> > On Tue, Jun 04, 2024 at 08:18:50AM -0400, Steven Rostedt wrote:
> > >
> > > Masami,
> >
Hi Steve, Masami,
On Tue, Jun 04, 2024 at 08:18:50AM -0400, Steven Rostedt wrote:
>
> Masami,
>
> This series passed all my tests, are you comfortable with me pushing
> them to linux-next?
As a heads-up (and not to block pushing this into next), I just gave
this a spin on arm64 atop v6.10-rc2,
Hi,
On Fri, May 31, 2024 at 11:33:31AM +0200, Vlastimil Babka wrote:
> Incomplete, help needed from ftrace/kprobe and bpf folks.
> - the generic error injection using kretprobes with
> override_function_with_return is handled in patch 2. The
> ALLOW_ERROR_INJECTION() annotation is extended so
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.
> > + * Architectures
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
> instructions
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 T"ope
[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 interrupts"&#
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:
> ta
e
fixups above.
Thanks,
Mark.
> 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.
>
/sys/kernel/tracing/current_tracer
# less /sys/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_u
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 interce
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 M
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 insta
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 to
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 definition
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 imple
e implicitly 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 belo
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 Mar
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_thre
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 enter_f
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 crea
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 T
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 enter_from_user_mo
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 He
ace_call;
> + 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
* the boot protocol.
>*/
> - writeq_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 |
e 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 t
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.
>
> Signed-o
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 EL
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
> &g
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 r
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 quest
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
>es
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 crea
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 t
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) regs
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 ker
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 Merg
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
he output of /proc/self/stack 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.
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
> > init_page_owner+
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
1 - 100 of 2158 matches
Mail list logo
