From: Sven Schnelle <svens@stackframe.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, amit.kachhap@arm.com,
catalin.marinas@arm.com, deller@gmx.de, duwe@suse.de,
James.Bottomley@HansenPartnership.com, james.morse@arm.com,
jeyu@kernel.org, jpoimboe@redhat.com, jthierry@redhat.com,
linux-parisc@vger.kernel.org, mingo@redhat.com,
peterz@infradead.org, rostedt@goodmis.org,
takahiro.akashi@linaro.org, will@kernel.org
Subject: Re: [PATCHv2 0/8] arm64: ftrace cleanup + FTRACE_WITH_REGS
Date: Fri, 1 Nov 2019 16:39:30 +0100 [thread overview]
Message-ID: <20191101153929.GA9053@t470p.stackframe.org> (raw)
In-Reply-To: <20191029165832.33606-1-mark.rutland@arm.com>
Hi Mark,
On Tue, Oct 29, 2019 at 04:58:24PM +0000, Mark Rutland wrote:
> Hi,
>
> This series is a reworked version of Torsten's FTRACE_WITH_REGS series
> [1]. I've tried to rework the existing code in preparatory patches so
> that the patchable-function-entry bits slot in with fewer surprises.
> This version is based on v5.4-rc3, and can be found in my
> arm64/ftrace-with-regs branch [2].
>
> Patch 1 adds an (optional) ftrace_init_nop(), which the core code uses
> to initialize callsites. This allows us to avoid a synthetic MCOUNT_ADDR
> symbol, and more cleanly separates the one-time initialization of the
> callsite from dynamic NOP<->CALL modification. Architectures which don't
> implement this get the existing ftrace_make_nop() with MCOUNT_ADDR.
>
> Recently parisc gained ftrace support using patchable-function-entry.
> Patch 2 makes the handling of module callsite locations common in
> kernel/module.c with a new FTRACE_CALLSITE_SECTION definition, and
> removed the newly redundant bits from arch/parisc.
>
> Patches 3 and 4 move the module PLT initialization to module load time,
> which simplifies runtime callsite modification. This also means that we
> don't transitently mark the module text RW, and will allow for the
> removal of module_disable_ro().
>
> Patches 5 and 6 add some trivial infrastructure, with patch 7 finally
> adding FTRACE_WITH_REGS support. Additional work will be required for
> livepatching (e.g. implementing reliable stack trace), which is
> commented as part of patch 7.
>
> Patch 8 is a trivial cleanup atop of the rest of the series, making the
> code easier to read and less susceptible to config-specific breakage.
>
> Since v1 [3]:
> * Add a couple of people to Cc
> * Fold in Ard's Reviewed-by tag
> * Rename ftrace_code_init_disabled() to ftrace_nop_initialize()
> * Move ftrace_init_nop() to <linux/ftrace.h>, with kerneldoc
> * Update kerneldoc for rec parameters
[..]
I tested this series on parisc both with ftracing kernel internal functions and
module functions. Both are working fine, so feel free to add my
Tested-by: Sven Schnelle <svens@stackframe.org>
Regards
Sven
WARNING: multiple messages have this Message-ID (diff)
From: Sven Schnelle <svens@stackframe.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: jthierry@redhat.com, linux-parisc@vger.kernel.org,
peterz@infradead.org, catalin.marinas@arm.com, deller@gmx.de,
jpoimboe@redhat.com, linux-kernel@vger.kernel.org,
rostedt@goodmis.org, James.Bottomley@HansenPartnership.com,
takahiro.akashi@linaro.org, mingo@redhat.com,
james.morse@arm.com, jeyu@kernel.org, amit.kachhap@arm.com,
will@kernel.org, duwe@suse.de,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv2 0/8] arm64: ftrace cleanup + FTRACE_WITH_REGS
Date: Fri, 1 Nov 2019 16:39:30 +0100 [thread overview]
Message-ID: <20191101153929.GA9053@t470p.stackframe.org> (raw)
In-Reply-To: <20191029165832.33606-1-mark.rutland@arm.com>
Hi Mark,
On Tue, Oct 29, 2019 at 04:58:24PM +0000, Mark Rutland wrote:
> Hi,
>
> This series is a reworked version of Torsten's FTRACE_WITH_REGS series
> [1]. I've tried to rework the existing code in preparatory patches so
> that the patchable-function-entry bits slot in with fewer surprises.
> This version is based on v5.4-rc3, and can be found in my
> arm64/ftrace-with-regs branch [2].
>
> Patch 1 adds an (optional) ftrace_init_nop(), which the core code uses
> to initialize callsites. This allows us to avoid a synthetic MCOUNT_ADDR
> symbol, and more cleanly separates the one-time initialization of the
> callsite from dynamic NOP<->CALL modification. Architectures which don't
> implement this get the existing ftrace_make_nop() with MCOUNT_ADDR.
>
> Recently parisc gained ftrace support using patchable-function-entry.
> Patch 2 makes the handling of module callsite locations common in
> kernel/module.c with a new FTRACE_CALLSITE_SECTION definition, and
> removed the newly redundant bits from arch/parisc.
>
> Patches 3 and 4 move the module PLT initialization to module load time,
> which simplifies runtime callsite modification. This also means that we
> don't transitently mark the module text RW, and will allow for the
> removal of module_disable_ro().
>
> Patches 5 and 6 add some trivial infrastructure, with patch 7 finally
> adding FTRACE_WITH_REGS support. Additional work will be required for
> livepatching (e.g. implementing reliable stack trace), which is
> commented as part of patch 7.
>
> Patch 8 is a trivial cleanup atop of the rest of the series, making the
> code easier to read and less susceptible to config-specific breakage.
>
> Since v1 [3]:
> * Add a couple of people to Cc
> * Fold in Ard's Reviewed-by tag
> * Rename ftrace_code_init_disabled() to ftrace_nop_initialize()
> * Move ftrace_init_nop() to <linux/ftrace.h>, with kerneldoc
> * Update kerneldoc for rec parameters
[..]
I tested this series on parisc both with ftracing kernel internal functions and
module functions. Both are working fine, so feel free to add my
Tested-by: Sven Schnelle <svens@stackframe.org>
Regards
Sven
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-11-01 15:39 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-29 16:58 [PATCHv2 0/8] arm64: ftrace cleanup + FTRACE_WITH_REGS Mark Rutland
2019-10-29 16:58 ` Mark Rutland
2019-10-29 16:58 ` [PATCHv2 1/8] ftrace: add ftrace_init_nop() Mark Rutland
2019-10-29 16:58 ` Mark Rutland
2019-10-30 15:00 ` Miroslav Benes
2019-10-30 15:00 ` Miroslav Benes
2019-11-02 12:19 ` Amit Daniel Kachhap
2019-11-02 12:19 ` Amit Daniel Kachhap
2019-11-04 13:11 ` Steven Rostedt
2019-11-04 13:11 ` Steven Rostedt
2019-11-05 6:59 ` Amit Kachhap
2019-11-05 6:59 ` Amit Kachhap
2019-11-04 13:36 ` Mark Rutland
2019-11-04 13:36 ` Mark Rutland
2019-11-05 6:47 ` Amit Kachhap
2019-11-05 6:47 ` Amit Kachhap
2019-11-06 14:15 ` Mark Rutland
2019-11-06 14:15 ` Mark Rutland
2019-11-07 4:40 ` Amit Kachhap
2019-11-07 4:40 ` Amit Kachhap
2019-11-04 13:16 ` Steven Rostedt
2019-11-04 13:16 ` Steven Rostedt
2019-11-04 13:38 ` Mark Rutland
2019-11-04 13:38 ` Mark Rutland
2019-11-04 13:53 ` Steven Rostedt
2019-11-04 13:53 ` Steven Rostedt
2019-10-29 16:58 ` [PATCHv2 2/8] module/ftrace: handle patchable-function-entry Mark Rutland
2019-10-29 16:58 ` Mark Rutland
2019-10-30 15:03 ` Torsten Duwe
2019-10-30 15:03 ` Torsten Duwe
2019-10-31 9:02 ` Mark Rutland
2019-10-31 9:02 ` Mark Rutland
2019-10-31 11:42 ` Torsten Duwe
2019-10-31 11:42 ` Torsten Duwe
2019-10-31 13:00 ` Mark Rutland
2019-10-31 13:00 ` Mark Rutland
2019-11-04 13:28 ` Steven Rostedt
2019-11-04 13:28 ` Steven Rostedt
2019-11-04 14:00 ` Mark Rutland
2019-11-04 14:00 ` Mark Rutland
2019-11-04 13:25 ` Steven Rostedt
2019-11-04 13:25 ` Steven Rostedt
2019-11-04 15:51 ` Mark Rutland
2019-11-04 15:51 ` Mark Rutland
2019-11-04 20:58 ` Helge Deller
2019-11-04 20:58 ` Helge Deller
2019-11-05 8:59 ` Miroslav Benes
2019-11-05 8:59 ` Miroslav Benes
2019-10-29 16:58 ` [PATCHv2 3/8] arm64: module: rework special section handling Mark Rutland
2019-10-29 16:58 ` Mark Rutland
2019-10-30 15:25 ` Miroslav Benes
2019-10-30 15:25 ` Miroslav Benes
2019-10-29 16:58 ` [PATCHv2 4/8] arm64: module/ftrace: intialize PLT at load time Mark Rutland
2019-10-29 16:58 ` Mark Rutland
2019-11-02 12:20 ` Amit Daniel Kachhap
2019-11-02 12:20 ` Amit Daniel Kachhap
2019-11-04 13:55 ` Mark Rutland
2019-11-04 13:55 ` Mark Rutland
2019-10-29 16:58 ` [PATCHv2 5/8] arm64: insn: add encoder for MOV (register) Mark Rutland
2019-10-29 16:58 ` Mark Rutland
2019-10-29 16:58 ` [PATCHv2 6/8] arm64: asm-offsets: add S_FP Mark Rutland
2019-10-29 16:58 ` Mark Rutland
2019-10-29 16:58 ` [PATCHv2 7/8] arm64: implement ftrace with regs Mark Rutland
2019-10-29 16:58 ` Mark Rutland
2019-11-02 12:21 ` Amit Daniel Kachhap
2019-11-02 12:21 ` Amit Daniel Kachhap
2019-11-04 13:51 ` Mark Rutland
2019-11-04 13:51 ` Mark Rutland
[not found] ` <CANW9uyug8WKN2fR-FmcW-C_OO_OQ_AvukM+BR7wqiJ9eFQMO9Q@mail.gmail.com>
2019-11-15 7:45 ` Torsten Duwe
2019-11-15 7:45 ` Torsten Duwe
2019-11-15 13:59 ` Mark Rutland
2019-11-15 13:59 ` Mark Rutland
2019-10-29 16:58 ` [PATCHv2 8/8] arm64: ftrace: minimize ifdeffery Mark Rutland
2019-10-29 16:58 ` Mark Rutland
2019-10-30 17:02 ` [PATCHv2 0/8] arm64: ftrace cleanup + FTRACE_WITH_REGS Torsten Duwe
2019-10-30 17:02 ` Torsten Duwe
2019-10-31 17:16 ` Torsten Duwe
2019-10-31 17:16 ` Torsten Duwe
2019-11-01 9:08 ` Mark Rutland
2019-11-01 9:08 ` Mark Rutland
2019-11-01 15:39 ` Sven Schnelle [this message]
2019-11-01 15:39 ` Sven Schnelle
2019-11-01 16:28 ` Mark Rutland
2019-11-01 16:28 ` Mark Rutland
2019-11-02 12:12 ` Amit Daniel Kachhap
2019-11-02 12:12 ` Amit Daniel Kachhap
2019-11-04 12:56 ` Will Deacon
2019-11-04 12:56 ` Will Deacon
2019-11-04 13:03 ` Amit Kachhap
2019-11-04 13:03 ` Amit Kachhap
2019-11-04 14:04 ` Mark Rutland
2019-11-04 14:04 ` Mark Rutland
2019-11-05 7:06 ` Amit Kachhap
2019-11-05 7:06 ` Amit Kachhap
2019-11-07 11:31 ` Catalin Marinas
2019-11-07 11:31 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191101153929.GA9053@t470p.stackframe.org \
--to=svens@stackframe.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=amit.kachhap@arm.com \
--cc=catalin.marinas@arm.com \
--cc=deller@gmx.de \
--cc=duwe@suse.de \
--cc=james.morse@arm.com \
--cc=jeyu@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=jthierry@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=takahiro.akashi@linaro.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.