All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Torsten Duwe <duwe@lst.de>
Cc: Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Julien Thierry <julien.thierry@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Amit Daniel Kachhap <amit.kachhap@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, live-patching@vger.kernel.org
Subject: Re: [PATCH v7 1/3] arm64: replace -pg with CC_FLAGS_FTRACE in Makefiles
Date: Fri, 18 Jan 2019 17:24:56 +0000	[thread overview]
Message-ID: <20190118172455.GF12256@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <20190118163904.CD7BA68CEB@newverein.lst.de>

Hi Torsten,

On Fri, Jan 18, 2019 at 05:39:04PM +0100, Torsten Duwe wrote:
> Ftrace instrumentation might also be introduced by
> -fpatchable-function-entry, not only -pg. Ensure the Makefiles are
> flexible to filter out the respective flags in "notrace" directories.

I think this is a cleanup regardless of whether we use
-fpatchable-function-entry.

Can we please give this a more complete description, e.g.

| Currently arm64 makefiles assume that ftrace will use '-pg', and remove
| this flag specifically, rather than the contents of $(CC_FLAGS_FTRACE).
| 
| In preparation for arm64 supporting ftrace built on other compiler
| options, let's have the arm64 makefiles remove the $(CC_FLAGS_FTRACE)
| flags, whatever these may be, rather than assuming '-pg'. 
|
| There should be no functional change as a result of this patch.

> 
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> 
> ---
>  arch/arm64/kernel/Makefile            |    6 +++---
>  drivers/firmware/efi/libstub/Makefile |    3 ++-

This misses arch/arm64/lib/Makefile and mm/kasan/makefile.

Could we please split this into three patches, addressing:

* arm64
* efistub
* kasan

... since those have distinct maintainers. All those patches can be part
of this series, but having them as separate patches is a bit nicer for
review.

>  2 files changed, 5 insertions(+), 4 deletions(-)
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -7,9 +7,9 @@ CPPFLAGS_vmlinux.lds	:= -DTEXT_OFFSET=$(
>  AFLAGS_head.o		:= -DTEXT_OFFSET=$(TEXT_OFFSET)
>  CFLAGS_armv8_deprecated.o := -I$(src)
>  
> -CFLAGS_REMOVE_ftrace.o = -pg
> -CFLAGS_REMOVE_insn.o = -pg
> -CFLAGS_REMOVE_return_address.o = -pg
> +CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
> +CFLAGS_REMOVE_insn.o = $(CC_FLAGS_FTRACE)
> +CFLAGS_REMOVE_return_address.o = $(CC_FLAGS_FTRACE)
>  
>  # Object file lists.
>  obj-y			:= debug-monitors.o entry.o irq.o fpsimd.o		\
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -16,7 +16,8 @@ cflags-$(CONFIG_X86)		+= -m$(BITS) -D__K
>  
>  # arm64 uses the full KBUILD_CFLAGS so it's necessary to explicitly
>  # disable the stackleak plugin
> -cflags-$(CONFIG_ARM64)		:= $(subst -pg,,$(KBUILD_CFLAGS)) -fpie \
> +cflags-$(CONFIG_ARM64)		:= $(filter-out $(CC_FLAGS_FTRACE)\
> +				  ,$(KBUILD_CFLAGS)) -fpie \
>  				   $(DISABLE_STACKLEAK_PLUGIN)

Why do we need to swtich to using filter-out. AFAICT, subst works just fine.

To keepthis legible, it would be nicer to split it like:

cflags-$(CONFIG_ARM64)			:= $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \
					   -fpie $(DISABLE_STACKLEAK_PLUGIN)

>  cflags-$(CONFIG_ARM)		:= $(subst -pg,,$(KBUILD_CFLAGS)) \
>  				   -fno-builtin -fpic \

Please clean up this instance too, at least for consistency.

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Torsten Duwe <duwe@lst.de>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Julien Thierry <julien.thierry@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Ingo Molnar <mingo@redhat.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Amit Daniel Kachhap <amit.kachhap@arm.com>,
	live-patching@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 1/3] arm64: replace -pg with CC_FLAGS_FTRACE in Makefiles
Date: Fri, 18 Jan 2019 17:24:56 +0000	[thread overview]
Message-ID: <20190118172455.GF12256@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <20190118163904.CD7BA68CEB@newverein.lst.de>

Hi Torsten,

On Fri, Jan 18, 2019 at 05:39:04PM +0100, Torsten Duwe wrote:
> Ftrace instrumentation might also be introduced by
> -fpatchable-function-entry, not only -pg. Ensure the Makefiles are
> flexible to filter out the respective flags in "notrace" directories.

I think this is a cleanup regardless of whether we use
-fpatchable-function-entry.

Can we please give this a more complete description, e.g.

| Currently arm64 makefiles assume that ftrace will use '-pg', and remove
| this flag specifically, rather than the contents of $(CC_FLAGS_FTRACE).
| 
| In preparation for arm64 supporting ftrace built on other compiler
| options, let's have the arm64 makefiles remove the $(CC_FLAGS_FTRACE)
| flags, whatever these may be, rather than assuming '-pg'. 
|
| There should be no functional change as a result of this patch.

> 
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> 
> ---
>  arch/arm64/kernel/Makefile            |    6 +++---
>  drivers/firmware/efi/libstub/Makefile |    3 ++-

This misses arch/arm64/lib/Makefile and mm/kasan/makefile.

Could we please split this into three patches, addressing:

* arm64
* efistub
* kasan

... since those have distinct maintainers. All those patches can be part
of this series, but having them as separate patches is a bit nicer for
review.

>  2 files changed, 5 insertions(+), 4 deletions(-)
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -7,9 +7,9 @@ CPPFLAGS_vmlinux.lds	:= -DTEXT_OFFSET=$(
>  AFLAGS_head.o		:= -DTEXT_OFFSET=$(TEXT_OFFSET)
>  CFLAGS_armv8_deprecated.o := -I$(src)
>  
> -CFLAGS_REMOVE_ftrace.o = -pg
> -CFLAGS_REMOVE_insn.o = -pg
> -CFLAGS_REMOVE_return_address.o = -pg
> +CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
> +CFLAGS_REMOVE_insn.o = $(CC_FLAGS_FTRACE)
> +CFLAGS_REMOVE_return_address.o = $(CC_FLAGS_FTRACE)
>  
>  # Object file lists.
>  obj-y			:= debug-monitors.o entry.o irq.o fpsimd.o		\
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -16,7 +16,8 @@ cflags-$(CONFIG_X86)		+= -m$(BITS) -D__K
>  
>  # arm64 uses the full KBUILD_CFLAGS so it's necessary to explicitly
>  # disable the stackleak plugin
> -cflags-$(CONFIG_ARM64)		:= $(subst -pg,,$(KBUILD_CFLAGS)) -fpie \
> +cflags-$(CONFIG_ARM64)		:= $(filter-out $(CC_FLAGS_FTRACE)\
> +				  ,$(KBUILD_CFLAGS)) -fpie \
>  				   $(DISABLE_STACKLEAK_PLUGIN)

Why do we need to swtich to using filter-out. AFAICT, subst works just fine.

To keepthis legible, it would be nicer to split it like:

cflags-$(CONFIG_ARM64)			:= $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \
					   -fpie $(DISABLE_STACKLEAK_PLUGIN)

>  cflags-$(CONFIG_ARM)		:= $(subst -pg,,$(KBUILD_CFLAGS)) \
>  				   -fno-builtin -fpic \

Please clean up this instance too, at least for consistency.

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-01-18 17:25 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 16:37 [PATCH v7 0/3] arm64: ftrace with regs Torsten Duwe
2019-01-18 16:37 ` Torsten Duwe
2019-01-18 16:39 ` [PATCH v7 1/3] arm64: replace -pg with CC_FLAGS_FTRACE in Makefiles Torsten Duwe
2019-01-18 16:39   ` Torsten Duwe
2019-01-18 17:24   ` Mark Rutland [this message]
2019-01-18 17:24     ` Mark Rutland
2019-01-18 16:39 ` [PATCH v7 2/3] arm64: implement ftrace with regs Torsten Duwe
2019-01-18 16:39   ` Torsten Duwe
2019-01-22  1:39   ` Singh, Balbir
2019-01-22  1:39     ` Singh, Balbir
2019-01-22 13:09     ` Torsten Duwe
2019-01-22 13:09       ` Torsten Duwe
2019-01-23 20:38       ` Singh, Balbir
2019-01-23 20:38         ` Singh, Balbir
2019-01-22 10:18   ` Julien Thierry
2019-01-22 10:18     ` Julien Thierry
2019-01-22 13:28     ` Torsten Duwe
2019-01-22 13:28       ` Torsten Duwe
2019-01-22 13:49       ` Julien Thierry
2019-01-22 13:49         ` Julien Thierry
2019-01-22 13:55       ` Ard Biesheuvel
2019-01-22 13:55         ` Ard Biesheuvel
2019-02-04 12:03         ` Torsten Duwe
2019-02-04 12:03           ` Torsten Duwe
2019-02-04 13:43           ` Ard Biesheuvel
2019-02-04 13:43             ` Ard Biesheuvel
2019-02-06  8:59   ` Julien Thierry
2019-02-06  8:59     ` Julien Thierry
2019-02-06  9:30     ` Julien Thierry
2019-02-06  9:30       ` Julien Thierry
2019-02-06 14:09     ` Steven Rostedt
2019-02-06 14:09       ` Steven Rostedt
2019-02-06 15:05     ` Torsten Duwe
2019-02-06 15:05       ` Torsten Duwe
2019-02-07 10:33       ` Julien Thierry
2019-02-07 10:33         ` Julien Thierry
2019-02-07 12:51         ` Torsten Duwe
2019-02-07 12:51           ` Torsten Duwe
2019-02-07 13:47           ` Julien Thierry
2019-02-07 13:47             ` Julien Thierry
2019-02-07 14:51         ` Steven Rostedt
2019-02-07 14:51           ` Steven Rostedt
2019-02-07 14:58           ` Julien Thierry
2019-02-07 14:58             ` Julien Thierry
2019-02-07 15:00           ` Torsten Duwe
2019-02-07 15:00             ` Torsten Duwe
2019-04-03  2:48   ` Mark Rutland
2019-04-03  2:48     ` Mark Rutland
2019-04-03 12:30     ` Steven Rostedt
2019-04-03 12:30       ` Steven Rostedt
2019-04-03 13:05     ` Torsten Duwe
2019-04-03 13:05       ` Torsten Duwe
2019-01-18 16:39 ` [PATCH v7 3/3] arm64: use -fpatchable-function-entry if available Torsten Duwe
2019-01-18 16:39   ` Torsten Duwe

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=20190118172455.GF12256@lakrids.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=amit.kachhap@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=duwe@lst.de \
    --cc=jpoimboe@redhat.com \
    --cc=julien.thierry@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=will.deacon@arm.com \
    /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.