| Message ID | 20181001141643.331EE68BC7@newverein.lst.de (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | arm64 live patching | expand |
Hi Torsten, On 1 October 2018 at 16:16, Torsten Duwe <duwe@lst.de> wrote: > In commit 06aeaaeabf69da4, many ftrace-related config options are > consolidated. By accident, I guess, the choice about DYNAMIC_FTRACE > and DYNAMIC_FTRACE_WITH_REGS is no longer available explicitly but > determined by the sole availability on the architecture. > > This makes it hard to introduce DYNAMIC_FTRACE_WITH_REGS if it depends > on new compiler features or other new properties of the toolchain > without breaking existing configurations. > > This patch turns the def_bool into an actual choice. Should the toolchain > not meet the requirements for _WITH_REGS it can be turned off. > I guess we now have Kbuild/Kconfig support for this, no? I mean, we can now show/hide options depending on the capabilities of the toolchain. I am not saying it would be a better approach, though - I'd rather have a warning than have things silently disabled, but other people may think differently. > Signed-off-by: Torsten Duwe <duwe@suse.de> > > > --- a/kernel/trace/Kconfig > +++ b/kernel/trace/Kconfig > @@ -508,9 +508,15 @@ config DYNAMIC_FTRACE > otherwise has native performance as long as no tracing is active. > > config DYNAMIC_FTRACE_WITH_REGS > - def_bool y > + bool "Include register content tracking in dynamic ftrace facility" > + default y > depends on DYNAMIC_FTRACE > depends on HAVE_DYNAMIC_FTRACE_WITH_REGS > + help > + This architecture supports the inspection of register contents, > + as passed between functions, at the dynamic ftrace points. > + This is also a prerequisite for Kernel Live Patching (KLP). > + When in doubt, say Y. > > config FUNCTION_PROFILER > bool "Kernel function profiler"
On Mon, Oct 01, 2018 at 04:52:27PM +0200, Ard Biesheuvel wrote: > > I guess we now have Kbuild/Kconfig support for this, no? I mean, we > can now show/hide options depending on the capabilities of the > toolchain. Config options depending on flags availability? > I am not saying it would be a better approach, though - I'd rather > have a warning than have things silently disabled, but other people > may think differently. Even then this switch has to be enabled, no matter who or what sets it. Note that this patch leaves everything as-is. Only arm64 users with "old" compilers would need to take action. Torsten
On 1 October 2018 at 17:03, Torsten Duwe <duwe@lst.de> wrote: > On Mon, Oct 01, 2018 at 04:52:27PM +0200, Ard Biesheuvel wrote: >> >> I guess we now have Kbuild/Kconfig support for this, no? I mean, we >> can now show/hide options depending on the capabilities of the >> toolchain. > > Config options depending on flags availability? > Yes. Note that 'make menuconfig' now prints the compiler version at the top, and kconfig options can now 'depend' on compiler features, although I must admit I don't know how it works. >> I am not saying it would be a better approach, though - I'd rather >> have a warning than have things silently disabled, but other people >> may think differently. > > Even then this switch has to be enabled, no matter who or what sets it. > Note that this patch leaves everything as-is. Only arm64 users with > "old" compilers would need to take action. > > Torsten >
On Mon, Oct 01, 2018 at 05:06:06PM +0200, Ard Biesheuvel wrote: > On 1 October 2018 at 17:03, Torsten Duwe <duwe@lst.de> wrote: > > On Mon, Oct 01, 2018 at 04:52:27PM +0200, Ard Biesheuvel wrote: > >> > >> I guess we now have Kbuild/Kconfig support for this, no? I mean, we > >> can now show/hide options depending on the capabilities of the > >> toolchain. > > > > Config options depending on flags availability? > > > Yes. Note that 'make menuconfig' now prints the compiler version at > the top, and kconfig options can now 'depend' on compiler features, Ah, cool, got it. So unless anyone else thinks this patch is useful, feel free to disregard it ;-) Point taken. Torsten
On Mon, 1 Oct 2018 17:10:37 +0200 Torsten Duwe <duwe@lst.de> wrote: > On Mon, Oct 01, 2018 at 05:06:06PM +0200, Ard Biesheuvel wrote: > > On 1 October 2018 at 17:03, Torsten Duwe <duwe@lst.de> wrote: > > > On Mon, Oct 01, 2018 at 04:52:27PM +0200, Ard Biesheuvel wrote: > > >> > > >> I guess we now have Kbuild/Kconfig support for this, no? I mean, we > > >> can now show/hide options depending on the capabilities of the > > >> toolchain. > > > > > > Config options depending on flags availability? > > > > > Yes. Note that 'make menuconfig' now prints the compiler version at > > the top, and kconfig options can now 'depend' on compiler features, > > Ah, cool, got it. So unless anyone else thinks this patch is useful, > feel free to disregard it ;-) Point taken. > Yes, please don't apply this patch. Have the build system figure out if the tool chain can handle it or not. -- Steve
--- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -508,9 +508,15 @@ config DYNAMIC_FTRACE otherwise has native performance as long as no tracing is active. config DYNAMIC_FTRACE_WITH_REGS - def_bool y + bool "Include register content tracking in dynamic ftrace facility" + default y depends on DYNAMIC_FTRACE depends on HAVE_DYNAMIC_FTRACE_WITH_REGS + help + This architecture supports the inspection of register contents, + as passed between functions, at the dynamic ftrace points. + This is also a prerequisite for Kernel Live Patching (KLP). + When in doubt, say Y. config FUNCTION_PROFILER bool "Kernel function profiler"
In commit 06aeaaeabf69da4, many ftrace-related config options are consolidated. By accident, I guess, the choice about DYNAMIC_FTRACE and DYNAMIC_FTRACE_WITH_REGS is no longer available explicitly but determined by the sole availability on the architecture. This makes it hard to introduce DYNAMIC_FTRACE_WITH_REGS if it depends on new compiler features or other new properties of the toolchain without breaking existing configurations. This patch turns the def_bool into an actual choice. Should the toolchain not meet the requirements for _WITH_REGS it can be turned off. Signed-off-by: Torsten Duwe <duwe@suse.de>