All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Torsten Duwe <duwe@suse.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Jessica Yu <jeyu@kernel.org>, Helge Deller <deller@gmx.de>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	linux-kernel@vger.kernel.org, amit.kachhap@arm.com,
	catalin.marinas@arm.com, james.morse@arm.com,
	jpoimboe@redhat.com, jthierry@redhat.com,
	linux-parisc@vger.kernel.org, mingo@redhat.com,
	peterz@infradead.org, rostedt@goodmis.org, svens@stackframe.org,
	takahiro.akashi@linaro.org, will@kernel.org
Subject: Re: [PATCHv2 2/8] module/ftrace: handle patchable-function-entry
Date: Thu, 31 Oct 2019 09:02:32 +0000	[thread overview]
Message-ID: <20191031090231.GA3340@blommer> (raw)
In-Reply-To: <20191030150302.GA965@suse.de>

On Wed, Oct 30, 2019 at 04:03:02PM +0100, Torsten Duwe wrote:
> On Tue, Oct 29, 2019 at 04:58:26PM +0000, Mark Rutland wrote:
> > When using patchable-function-entry, the compiler will record the
> > callsites into a section named "__patchable_function_entries" rather
> > than "__mcount_loc". Let's abstract this difference behind a new
> > FTRACE_CALLSITE_SECTION, so that architectures don't have to handle this
> > explicitly (e.g. with custom module linker scripts).
> > 
> > As parisc currently handles this explicitly, it is fixed up accordingly,
> > with its custom linker script removed. Since FTRACE_CALLSITE_SECTION is
> > only defined when DYNAMIC_FTRACE is selected, the parisc module loading
> > code is updated to only use the definition in that case. When
> > DYNAMIC_FTRACE is not selected, modules shouldn't have this section, so
> > this removes some redundant work in that case.
> > 
> > I built parisc generic-{32,64}bit_defconfig with DYNAMIC_FTRACE enabled,
> > and verified that the section made it into the .ko files for modules.
> 
> This is because of remaining #ifdeffery in include/asm-generic/vmlinux.lds.h:
> 
> #ifdef CC_USING_PATCHABLE_FUNCTION_ENTRY
> #define MCOUNT_REC()    . = ALIGN(8);                           \
>                         __start_mcount_loc = .;                 \
>                         KEEP(*(__patchable_function_entries))   \
>                         __stop_mcount_loc = .;
> #else
> #define MCOUNT_REC()    . = ALIGN(8);                           \
>                         __start_mcount_loc = .;                 \
>                         KEEP(*(__mcount_loc))                   \
>                         __stop_mcount_loc = .;
> #endif

For modules we use a combination of scripts/module-common.lds and an
architecture's own module.lds, not vmlinux.lds.h. So I don't think the above is
relevant for modules.

For modules the kernel's ELF loader looks for the ELF ection, not the
__{start,stop}_mcount_loc symbols that we use for the main kernel image.

FWIW, when building a module, I see the following linker operations:

| [mark@blommer:~/src/linux]% toolchain korg gcc-8.1.0-nolibc make V=1 ARCH=arm64 CROSS_COMPILE=aarch64-linux- arch/arm64/crypto/sha512-ce.ko | grep aarch64-linux-ld
|   aarch64-linux-ld  -EL  -maarch64elf    -r -o arch/arm64/crypto/sha512-ce.o arch/arm64/crypto/sha512-ce-glue.o arch/arm64/crypto/sha512-ce-core.o
|   aarch64-linux-ld -r  -EL  -maarch64elf  --build-id  -T ./scripts/module-common.lds -T ./arch/arm64/kernel/module.lds -o arch/arm64/crypto/sha512-ce.ko arch/arm64/crypto/sha512-ce.o arch/arm64/crypto/sha512-ce.mod.o;  true

> Maybe you want to tackle that as well? I suggest to have at least one
> FTRACE_CALLSITE_SECTION definition without double quotes. Alternatively, my
> earlier solution just kept both sections, in case either one or both are
> present.
> 
>                         KEEP(*(__patchable_function_entries))   \
>                         KEEP(*(__mcount_loc))                   \

I agree that the CC_USING_PATCHABLE_FUNCTION_ENTRY ifdeffery could be
simplified, and that it would be nice to consistently use
FTRACE_CALLSITE_SECTION if we can. However, the generic linker script doesn't
include anything, and I don't see a good location for that to live.

What I could do is add an explicit comment:

/*
 * The ftrace call sites are logged to a section whose name depends on the
 * compiler option used. A given kernel image will only use one, AKA
 * FTRACE_CALLSITE_SECTION. We capture all of them here to avoid header
 * dependencies.
 */
#define MCOUNT_REC()						\
			. = ALIGN(8);				\
			__start_mcount_loc = .;			\
			KEEP(*(__patchable_function_entries))   \
			KEEP(*(__mcount_loc))                   \
			__stop_mcount_loc = .;			

... which should make the dependency clear. Does that sound good to you?

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Torsten Duwe <duwe@suse.de>
Cc: jthierry@redhat.com, linux-parisc@vger.kernel.org,
	peterz@infradead.org, catalin.marinas@arm.com,
	Helge Deller <deller@gmx.de>,
	jpoimboe@redhat.com, linux-kernel@vger.kernel.org,
	rostedt@goodmis.org,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	takahiro.akashi@linaro.org, will@kernel.org, mingo@redhat.com,
	james.morse@arm.com, Jessica Yu <jeyu@kernel.org>,
	amit.kachhap@arm.com, svens@stackframe.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv2 2/8] module/ftrace: handle patchable-function-entry
Date: Thu, 31 Oct 2019 09:02:32 +0000	[thread overview]
Message-ID: <20191031090231.GA3340@blommer> (raw)
In-Reply-To: <20191030150302.GA965@suse.de>

On Wed, Oct 30, 2019 at 04:03:02PM +0100, Torsten Duwe wrote:
> On Tue, Oct 29, 2019 at 04:58:26PM +0000, Mark Rutland wrote:
> > When using patchable-function-entry, the compiler will record the
> > callsites into a section named "__patchable_function_entries" rather
> > than "__mcount_loc". Let's abstract this difference behind a new
> > FTRACE_CALLSITE_SECTION, so that architectures don't have to handle this
> > explicitly (e.g. with custom module linker scripts).
> > 
> > As parisc currently handles this explicitly, it is fixed up accordingly,
> > with its custom linker script removed. Since FTRACE_CALLSITE_SECTION is
> > only defined when DYNAMIC_FTRACE is selected, the parisc module loading
> > code is updated to only use the definition in that case. When
> > DYNAMIC_FTRACE is not selected, modules shouldn't have this section, so
> > this removes some redundant work in that case.
> > 
> > I built parisc generic-{32,64}bit_defconfig with DYNAMIC_FTRACE enabled,
> > and verified that the section made it into the .ko files for modules.
> 
> This is because of remaining #ifdeffery in include/asm-generic/vmlinux.lds.h:
> 
> #ifdef CC_USING_PATCHABLE_FUNCTION_ENTRY
> #define MCOUNT_REC()    . = ALIGN(8);                           \
>                         __start_mcount_loc = .;                 \
>                         KEEP(*(__patchable_function_entries))   \
>                         __stop_mcount_loc = .;
> #else
> #define MCOUNT_REC()    . = ALIGN(8);                           \
>                         __start_mcount_loc = .;                 \
>                         KEEP(*(__mcount_loc))                   \
>                         __stop_mcount_loc = .;
> #endif

For modules we use a combination of scripts/module-common.lds and an
architecture's own module.lds, not vmlinux.lds.h. So I don't think the above is
relevant for modules.

For modules the kernel's ELF loader looks for the ELF ection, not the
__{start,stop}_mcount_loc symbols that we use for the main kernel image.

FWIW, when building a module, I see the following linker operations:

| [mark@blommer:~/src/linux]% toolchain korg gcc-8.1.0-nolibc make V=1 ARCH=arm64 CROSS_COMPILE=aarch64-linux- arch/arm64/crypto/sha512-ce.ko | grep aarch64-linux-ld
|   aarch64-linux-ld  -EL  -maarch64elf    -r -o arch/arm64/crypto/sha512-ce.o arch/arm64/crypto/sha512-ce-glue.o arch/arm64/crypto/sha512-ce-core.o
|   aarch64-linux-ld -r  -EL  -maarch64elf  --build-id  -T ./scripts/module-common.lds -T ./arch/arm64/kernel/module.lds -o arch/arm64/crypto/sha512-ce.ko arch/arm64/crypto/sha512-ce.o arch/arm64/crypto/sha512-ce.mod.o;  true

> Maybe you want to tackle that as well? I suggest to have at least one
> FTRACE_CALLSITE_SECTION definition without double quotes. Alternatively, my
> earlier solution just kept both sections, in case either one or both are
> present.
> 
>                         KEEP(*(__patchable_function_entries))   \
>                         KEEP(*(__mcount_loc))                   \

I agree that the CC_USING_PATCHABLE_FUNCTION_ENTRY ifdeffery could be
simplified, and that it would be nice to consistently use
FTRACE_CALLSITE_SECTION if we can. However, the generic linker script doesn't
include anything, and I don't see a good location for that to live.

What I could do is add an explicit comment:

/*
 * The ftrace call sites are logged to a section whose name depends on the
 * compiler option used. A given kernel image will only use one, AKA
 * FTRACE_CALLSITE_SECTION. We capture all of them here to avoid header
 * dependencies.
 */
#define MCOUNT_REC()						\
			. = ALIGN(8);				\
			__start_mcount_loc = .;			\
			KEEP(*(__patchable_function_entries))   \
			KEEP(*(__mcount_loc))                   \
			__stop_mcount_loc = .;			

... which should make the dependency clear. Does that sound good to you?

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-10-31  9:02 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 [this message]
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
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=20191031090231.GA3340@blommer \
    --to=mark.rutland@arm.com \
    --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=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=svens@stackframe.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.