[PATCH v9 3/4] scripts: add verifier script for builtin module range data

.*.cmd file used to compile the object as suggested in [0]) - For each symbol in that object, verify that the built-in module association (or lack thereof) matches the annotation given to the symbol. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock

[PATCH v9 2/4] kbuild: generate offset range data for builtin modules

rking on a module(s) range, close that range Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock Reviewed-by: Alan Maguire Reviewed-by: Steven Rostedt (Google) --- Changes since v8: - Added support for built-in Rust modules. - Added optional 4th argument to specify kernel build

[PATCH v9 4/4] module: add install target for modules.builtin.ranges

When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges file should be installed in the module install location. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v3: - Only install modules.builtin.ranges if CONFIG_BUILTIN_MODULE_RANGES=y

[PATCH v9 0/4] Generate address range data for built-in modules

x.map Kris Van Hees (5): trace: add CONFIG_BUILTIN_MODULE_RANGES option kbuild: generate a linker map for vmlinux.o module: script to generate offset ranges for builtin modules kbuild: generate modules.builtin.ranges when linking the kernel module: add install target for modules.builtin.r

[PATCH v9 1/4] kbuild: add mod(name,file)_flags to assembler flags for module objects

KBUILD_MODFILE is sufficient to generate the modules ranges data, KBUILD_MODNAME is passed as well for consistency with the C source code case. Signed-off-by: Kris Van Hees Reviewed-by: Steven Rostedt (Google) --- Changes since v8: - Fixed typos. - Explained KBUILD_MODNAME being

Re: [PATCH v8 2/4] kbuild: generate offset range data for builtin modules

On Fri, Aug 23, 2024 at 04:53:29PM +, Sami Tolvanen wrote: > Hi Kris, > > On Thu, Aug 22, 2024 at 02:19:39PM -0400, Kris Van Hees wrote: > > diff --git a/scripts/generate_builtin_ranges.awk > > b/scripts/generate_builtin_ranges.awk > > new file mode 10

[PATCH v8 1/4] kbuild: add mod(name,file)_flags to assembler flags for module objects

-off-by: Kris Van Hees Reviewed-by: Steven Rostedt (Google) --- scripts/Makefile.lib | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index fe3668dc4954..170f462537a8 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib

[PATCH v8 2/4] kbuild: generate offset range data for builtin modules

If we were working on a module(s) range, close that range Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock Reviewed-by: Alan Maguire Reviewed-by: Steven Rostedt (Google) --- Changes since v7: - Removed extra close(fn). - Make CONFIG_BUILTIN_MODULE_RANGES depend on !lTO.

[PATCH v8 4/4] module: add install target for modules.builtin.ranges

When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges file should be installed in the module install location. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v3: - Only install modules.builtin.ranges if CONFIG_BUILTIN_MODULE_RANGES=y

[PATCH v8 3/4] scripts: add verifier script for builtin module range data

.*.cmd file used to compile the object as suggested in [0]) - For each symbol in that object, verify that the built-in module association (or lack thereof) matches the annotation given to the symbol. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock

[PATCH v8 0/4] Generate address range data for built-in modules

ES to CONFIG_BUILTIN_MODULE_RANGES - Moved the config option to the tracers section - 2nd arg to generate_builtin_ranges.awk should be vmlinux.map Kris Van Hees (5): trace: add CONFIG_BUILTIN_MODULE_RANGES option kbuild: generate a linker map for vmlinux.o module: script to generate offset r

[PATCH v7 0/4] Generate address range data for built-in modules

rg to generate_builtin_ranges.awk should be vmlinux.map Kris Van Hees (5): trace: add CONFIG_BUILTIN_MODULE_RANGES option kbuild: generate a linker map for vmlinux.o module: script to generate offset ranges for builtin modules kbuild: generate modules.builtin.ranges when linking the kernel module: add in

[PATCH v7 2/4] kbuild: generate offset range data for builtin modules

If we were working on a module(s) range, close that range Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock Reviewed-by: Alan Maguire Reviewed-by: Steven Rostedt (Google) --- Changes since v6: - Applied Masahiro Yamada's suggestions (Kconfig, makefile, script). C

[PATCH v7 3/4] scripts: add verifier script for builtin module range data

.*.cmd file used to compile the object as suggested in [0]) - For each symbol in that object, verify that the built-in module association (or lack thereof) matches the annotation given to the symbol. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock

[PATCH v7 1/4] kbuild: add mod(name,file)_flags to assembler flags for module objects

-off-by: Kris Van Hees Reviewed-by: Steven Rostedt (Google) --- scripts/Makefile.lib | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index fe3668dc4954..170f462537a8 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib

[PATCH v7 4/4] module: add install target for modules.builtin.ranges

When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges file should be installed in the module install location. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v3: - Only install modules.builtin.ranges if CONFIG_BUILTIN_MODULE_RANGES=y

Re: [PATCH v6 3/4] scripts: add verifier script for builtin module range data

On Sun, Aug 18, 2024 at 03:40:36PM +0900, Masahiro Yamada wrote: > On Fri, Aug 16, 2024 at 12:04???AM Kris Van Hees > wrote: > > > > The modules.builtin.ranges offset range data for builtin modules is > > generated at compile time based on the list of built-in modules and

Re: [PATCH v6 2/4] kbuild, kconfig: generate offset range data for builtin modules

On Sun, Aug 18, 2024 at 03:19:36PM +0900, Masahiro Yamada wrote: > On Fri, Aug 16, 2024 at 12:04???AM Kris Van Hees > wrote: > > > The subject should be: > "kbuild: generate offset range data for builtin modules" > > > (Drop ", kconfig&qu

[PATCH v6 3/4] scripts: add verifier script for builtin module range data

.*.cmd file used to compile the object as suggested in [0]) - For each symbol in that object, verify that the built-in module association (or lack thereof) matches the annotation given to the symbol. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock

[PATCH v6 4/4] module: add install target for modules.builtin.ranges

When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges file should be installed in the module install location. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v3: - Only install modules.builtin.ranges if CONFIG_BUILTIN_MODULE_RANGES=y

[PATCH v6 2/4] kbuild, kconfig: generate offset range data for builtin modules

working on a module(s) range, close that range Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock Reviewed-by: Alan Maguire Reviewed-by: Steven Rostedt (Google) --- Changes since v5: - Removed unnecessary compatibility info from option description. Changes since v4:

[PATCH v6 1/4] kbuild: add mod(name,file)_flags to assembler flags for module objects

-off-by: Kris Van Hees Reviewed-by: Steven Rostedt (Google) --- scripts/Makefile.lib | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index fe3668dc4954..170f462537a8 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib

[PATCH v6 0/4] Generate address range data for built-in modules

modules.builtin.ranges in modules install target Changes since v1: - Renamed CONFIG_BUILTIN_RANGES to CONFIG_BUILTIN_MODULE_RANGES - Moved the config option to the tracers section - 2nd arg to generate_builtin_ranges.awk should be vmlinux.map Kris Van Hees (5): trace: add CONFIG_BUILTIN_MODULE_RANGES

Re: [PATCH v5 3/4] scripts: add verifier script for builtin module range data

On Wed, Aug 14, 2024 at 04:16:06PM -0400, Steven Rostedt wrote: > On Wed, 14 Aug 2024 15:59:58 -0400 > Kris Van Hees wrote: > > > > What does this mean? > > > > Hm, this is certainly why the validation script exists. I am surprised, > > though > >

Re: [PATCH v5 3/4] scripts: add verifier script for builtin module range data

d make it a config option so it can nbe enabled for those who might want to, e.g. for release building? Does that make sense? > On Mon, 15 Jul 2024 23:10:44 -0400 > Kris Van Hees wrote: > > > The modules.builtin.ranges offset range data for builtin modules is > > generated

Re: [PATCH v5 2/4] kbuild, kconfig: generate offset range data for builtin modules

On Wed, Aug 14, 2024 at 03:04:05PM -0400, Steven Rostedt wrote: > On Mon, 15 Jul 2024 23:10:43 -0400 > Kris Van Hees wrote: > > > The offset range data for builtin modules is generated using: > > - modules.builtin: associates object files with module names > > -

Re: [PATCH v5 1/4] kbuild: add mod(name,file)_flags to assembler flags for module objects

On Wed, Aug 14, 2024 at 01:17:46PM -0400, Steven Rostedt wrote: > On Mon, 15 Jul 2024 23:10:42 -0400 > Kris Van Hees wrote: > > > As mentioned before, should start off with the goal. > > In order to create the file at build time, modules.builtin.ranges, that >

Re: [PATCH v4 1/3] kbuild: add mod(name,file)_flags to assembler flags for module objects

On Fri, Jun 14, 2024 at 02:26:21PM -0400, Steven Rostedt wrote: > On Fri, 14 Jun 2024 14:10:58 -0400 > Kris Van Hees wrote: > > > On Fri, Jun 14, 2024 at 01:46:51PM -0400, Steven Rostedt wrote: > > > On Fri, 14 Jun 2024 13:14:26 -0400 > > > Kris Van Hees wrote

Re: [PATCH v4 2/3] kbuild, kconfig: generate offset range data for builtin modules

On Tue, Jun 18, 2024 at 11:57:38AM -0700, Luis Chamberlain wrote: > On Fri, Jun 14, 2024 at 01:14:27PM -0400, Kris Van Hees wrote: > > The offset range data for builtin modules is generated using: > > - modules.builtin: associates object files with module names > > - vmlin

[PATCH v5 4/4] module: add install target for modules.builtin.ranges

When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges file should be installed in the module install location. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Notes: Changes since v3: - Only install modules.builtin.ranges if CONFIG_BUILTIN_MODULE_RANGES=y

[PATCH v5 2/4] kbuild, kconfig: generate offset range data for builtin modules

he new one - If the symbol does not belong to any built-in modules: - It we were working on a module(s) range, close that range Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock Reviewed-by: Alan Maguire --- Notes: Changes since v4: - Improved commit description to expla

[PATCH v5 3/4] scripts: add verifier script for builtin module range data

.*.cmd file used to compile the object as suggested in [0]) - For each symbol in that object, verify that the built-in module association (or lack thereof) matches the annotation given to the symbol. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock Reviewed

[PATCH v5 1/4] kbuild: add mod(name,file)_flags to assembler flags for module objects

a_flags (similar to c_flags) makes it possible to identify which objects are compiled into modules for both C and assembler soure files. Signed-off-by: Kris Van Hees --- scripts/Makefile.lib | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.lib b/scripts

[PATCH v5 0/4] Generate address range data for built-in modules

config option to the tracers section - 2nd arg to generate_builtin_ranges.awk should be vmlinux.map Kris Van Hees (5): trace: add CONFIG_BUILTIN_MODULE_RANGES option kbuild: generate a linker map for vmlinux.o module: script to generate offset ranges for builtin modules kbuild: generate

Re: [PATCH v4 2/3] kbuild, kconfig: generate offset range data for builtin modules

be in the posted version. Again, sorry for have yet again overlooked that. Kris On Fri, Jun 14, 2024 at 01:14:27PM -0400, Kris Van Hees wrote: > The offset range data for builtin modules is generated using: > - modules.builtin: associates object files with module names > - vm

Re: [PATCH v4 1/3] kbuild: add mod(name,file)_flags to assembler flags for module objects

On Fri, Jun 14, 2024 at 01:46:51PM -0400, Steven Rostedt wrote: > On Fri, 14 Jun 2024 13:14:26 -0400 > Kris Van Hees wrote: > > > Module objects compiled from C source can be identified by the presence > > of -DKBUILD_MODFILE and -DKBUILD_MODNAME on their compile comma

[PATCH v4 3/3] module: add install target for modules.builtin.ranges

When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges file should be installed in the module install location. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v3: - Only install modules.builtin.ranges if CONFIG_BUILTIN_MODULE_RANGES=y --- scripts

[PATCH v4 2/3] kbuild, kconfig: generate offset range data for builtin modules

into the kernel image. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock Reviewed-by: Alan Maguire --- Changes since v3: - Consolidated patches 2 through 5 into a single patch - Move CONFIG_BUILTIN_MODULE_RANGES to Kconfig.debug - Make CONFIG_BUILTIN_MODULE_RANGES select CONFIG_VMLINUX_MAP

[PATCH v4 1/3] kbuild: add mod(name,file)_flags to assembler flags for module objects

$(modname_flags) to a_flags (similar to c_flags). Signed-off-by: Kris Van Hees --- scripts/Makefile.lib | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 3179747cbd2c..a2524ffd046f 100644 --- a/scripts/Makefile.lib +++ b/scripts

[PATCH v4 0/3] Generate address range data for built-in modules

to generate_builtin_ranges.awk should be vmlinux.map Kris Van Hees (5): trace: add CONFIG_BUILTIN_MODULE_RANGES option kbuild: generate a linker map for vmlinux.o module: script to generate offset ranges for builtin modules kbuild: generate modules.builtin.ranges when linking the kernel

Re: [PATCH v3 4/6] module: script to generate offset ranges for builtin modules

On Tue, May 21, 2024 at 01:53:27AM +0900, Masahiro Yamada wrote: > On Fri, May 17, 2024 at 1:31???PM Kris Van Hees > wrote: > > > > The offset range data for builtin modules is generated using: > > - modules.builtin.modinfo: associates object files with module names >

[PATCH v3 6/6] module: add install target for modules.builtin.ranges

When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges file should be installed in the module install location. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v2: - Include modules.builtin.ranges in modules install target --- scripts/Makefile.modinst

[PATCH v3 5/6] kbuild: generate modules.builtin.ranges when linking the kernel

Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v2: - 1st arg to generate_builtin_ranges.awk is now modules.builtin.modinfo - Use $(real-prereqs) rather than $(filter-out ...) --- scripts/Makefile.vmlinux | 16 1 file changed, 16 insertions(+) diff

[PATCH v3 4/6] module: script to generate offset ranges for builtin modules

order) offset ranges in that section that cover the symbols of one or more builtin modules. Multiple ranges can apply to a single module, and ranges can be shared between modules. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v2: - 1st arg to

[PATCH v3 3/6] kbuild: generate a linker map for vmlinux.o

When CONFIG_BUILTIN_MODULE_RANGES is set, a linker map for vmlinux.o needs to be generated. The generation of offset range data for builtin modules depends on that linker map to know what offsets in an ELF section belong to an object file for a particular builtin module. Signed-off-by: Kris Van

[PATCH v3 2/6] trace: add CONFIG_BUILTIN_MODULE_RANGES option

The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data is generated for kernel modules that are built into the kernel image. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock Reviewed-by: Alan Maguire --- Changes since v2: - Add explicit dependency on FTRACE for

[PATCH v3 1/6] kbuild: add mod(name,file)_flags to assembler flags for module objects

$(modname_flags) to a_flags (similar to c_flags). Signed-off-by: Kris Van Hees --- scripts/Makefile.lib | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 3179747cbd2cc..a2524ffd046f4 100644 --- a/scripts/Makefile.lib +++ b

[PATCH v3 0/6] Generate address range data for built-in modules

install target Changes since v1: - Renamed CONFIG_BUILTIN_RANGES to CONFIG_BUILTIN_MODULE_RANGES - Moved the config option to the tracers section - 2nd arg to generate_builtin_ranges.awk should be vmlinux.map Kris Van Hees (5): trace: add CONFIG_BUILTIN_MODULE_RANGES option kbuild: generate a

Re: [PATCH v2 0/6] Generate address range data for built-in modules

On Mon, May 13, 2024 at 01:43:15PM +0900, Masahiro Yamada wrote: > On Sun, May 12, 2024 at 7:42???AM Kris Van Hees > wrote: > > > > Especially for tracing applications, it is convenient to be able to > > refer to a symbol using a pair and to be able > > to tra

[PATCH v2 6/6] module: add install target for modules.builtin.ranges

When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges file should be installed in the module install location. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v1: - Renamed CONFIG_BUILTIN_RANGES to CONFIG_BUILTIN_MODULE_RANGES --- scripts

[PATCH v2 5/6] kbuild: generate modules.builtin.ranges when linking the kernel

Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v1: - Renamed CONFIG_BUILTIN_RANGES to CONFIG_BUILTIN_MODULE_RANGES --- scripts/Makefile.vmlinux | 17 + 1 file changed, 17 insertions(+) diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux

[PATCH v2 4/6] module: script to generate offset ranges for builtin modules

or more builtin modules. Multiple ranges can apply to a single module, and ranges can be shared between modules. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- Changes since v1: - Updated commit msg (vmlinux.o -> vmlinux.map) --- scripts/generate_builtin_ranges.awk |

[PATCH v2 3/6] kbuild: generate a linker map for vmlinux.o

When CONFIG_BUILTIN_MODULE_RANGES is set, a linker map for vmlinux.o needs to be generated. The generation of offset range data for builtin modules depends on that linker map to know what offsets in an ELF section belong to an object file for a particular builtin module. Signed-off-by: Kris Van

[PATCH v2 2/6] trace: add CONFIG_BUILTIN_MODULE_RANGES option

The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data is generated for kernel modules that are built into the kernel image. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock Reviewed-by: Alan Maguire --- Changes since v1: - Renamed CONFIG_BUILTIN_RANGES to

[PATCH v2 1/6] kbuild: add modules.builtin.objs

/vmlinux.lds.h). Orabug: 29891866 Signed-off-by: Luis Chamberlain Signed-off-by: Nick Alcock Reviewed-by: Nick Alcock Reviewed-by: Kris Van Hees --- Changes since v1: - None --- .gitignore | 2 +- Documentation/dontdiff | 2 +- Documentation/kbuild/kbuild.rst | 5

[PATCH v2 0/6] Generate address range data for built-in modules

-40KB. Changes since v1: - Renamed CONFIG_BUILTIN_RANGES to CONFIG_BUILTIN_MODULE_RANGES - Moved the config option to the tracers section - 2nd arg to generate_builtin_ranges.awk should be vmlinux.map Kris Van Hees (5): trace: add CONFIG_BUILTIN_MODULE_RANGES option kbuild: generate a linker ma

Re: [PATCH 2/6] module: add CONFIG_BUILTIN_RANGES option

On Sat, Dec 09, 2023 at 07:59:17AM +0900, Masami Hiramatsu wrote: > On Fri, 8 Dec 2023 00:07:48 -0500 > Kris Van Hees wrote: > > > The CONFIG_BUILTIN_RANGES option controls whether offset range data is > > generated for kernel modules that are built into the kernel image. &

[PATCH 6/6] module: add install target for modules.builtin.ranges

When CONFIG_BUILTIN_RANGES is enable, the modules.builtin.ranges file should be installed in the module install location. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- scripts/Makefile.modinst | 5 + 1 file changed, 5 insertions(+) diff --git a/scripts/Makefile.modinst b

[PATCH 5/6] kbuild: generate modules.builtin.ranges when linking the kernel

Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- scripts/Makefile.vmlinux | 17 + 1 file changed, 17 insertions(+) diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux index c9f3e03124d7..c23d40b023ff 100644 --- a/scripts/Makefile.vmlinux +++ b/scripts

[PATCH 4/6] module: script to generate offset ranges for builtin modules

more builtin modules. Multiple ranges can apply to a single module, and ranges can be shared between modules. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- scripts/generate_builtin_ranges.awk | 149 1 file changed, 149 insertions(+) create mode 100755

[PATCH 3/6] kbuild: generate a linker map for vmlinux.o

When CONFIG_BUILTIN_RANGES is set, a linker map for vmlinux.o needs to be generated. The generation of offset range data for builtin modules depends on that linker map to know what offsets in an ELF section belong to an object file for a particular builtin module. Signed-off-by: Kris Van Hees

[PATCH 2/6] module: add CONFIG_BUILTIN_RANGES option

The CONFIG_BUILTIN_RANGES option controls whether offset range data is generated for kernel modules that are built into the kernel image. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock Reviewed-by: Alan Maguire --- kernel/module/Kconfig | 17 + 1 file changed, 17

[PATCH 1/6] kbuild: add modules.builtin.objs

/vmlinux.lds.h). Orabug: 29891866 Signed-off-by: Luis Chamberlain Signed-off-by: Nick Alcock Reviewed-by: Nick Alcock Reviewed-by: Kris Van Hees --- .gitignore | 2 +- Documentation/dontdiff | 2 +- Documentation/kbuild/kbuild.rst | 5 + Makefile

[PATCH 0/6] Generate address range data for built-in modules

with the other modules.builtin.* files. The impact on the kernel build is minimal because everything is done using a single-pass AWK script. The generated data size is minimal as well, (depending on the exact kernel configuration) in the range of 500-600 lines, with a file size of 20-30KB. Kri

Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms

> > On the flip side, introducing these new symbols would enable tracers to > > directly employ the new names without any modifications, and humans could > > easily identify the symbol they are dealing with just by examining the > > name. > > These are the fundamental

Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms

On Thu, Oct 05, 2023 at 12:24:03PM -0400, Kris Van Hees wrote: > On Wed, Sep 27, 2023 at 05:35:16PM +, Alessandro Carminati (Red Hat) > wrote: > > It is not uncommon for drivers or modules related to similar peripherals > > to have symbols with the exact same name. >

Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms

On Wed, Sep 27, 2023 at 05:35:16PM +, Alessandro Carminati (Red Hat) wrote: > It is not uncommon for drivers or modules related to similar peripherals > to have symbols with the exact same name. > While this is not a problem for the kernel's binary itself, it becomes an > issue when attempting

Re: [PATCH V2 1/1 (was 0/1 by accident)] tools/dtrace: initial implementation of DTrace

On Wed, Jul 10, 2019 at 11:19:43PM +0200, Daniel Borkmann wrote: > On 07/10/2019 10:30 PM, Jonathan Corbet wrote: > > On Wed, 10 Jul 2019 21:32:25 +0200 > > Daniel Borkmann wrote: > > > >> Looks like you missed Brendan Gregg's prior feedback from v1 [0]. I haven't > >> seen a strong compelling ar

Re: [PATCH V2 1/1 (was 0/1 by accident)] tools/dtrace: initial implementation of DTrace

This patch's subject should of course be [PATCH V2 1/1] rather than 0/1. Sorry about that. On Wed, Jul 10, 2019 at 08:42:24AM -0700, Kris Van Hees wrote: > This initial implementation of a tiny subset of DTrace functionality > provides the following options: > > dtrace [-l

[PATCH V2 0/1] tools/dtrace: initial implementation of DTrace

e its only dependency (libbpf) is in the kernel tree under tools/lib/bpf. A simple 'make' in the tools/dtrace directory suffices. The 'dtrace' executable needs to run as root because BPF programs cannot be loaded by non-root users. Signed-off-by: Kris Van Hees Reviewed-by: Davi

[PATCH V2 0/1] tools/dtrace: initial implementation of DTrace

/bpf_sample.c = sample BPF program using two probe types I included an entry for the MAINTAINERS file. I offer to actively maintain this code, and to keep advancing its development. Cheers, Kris Van Hees

Re: [PATCH 1/1] tools/dtrace: initial implementation of DTrace

On Mon, Jul 08, 2019 at 02:15:37PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Jul 03, 2019 at 08:14:30PM -0700, Kris Van Hees escreveu: > > This initial implementation of a tiny subset of DTrace functionality > > provides the following options: > > > > dtrace

Re: [PATCH 1/1] tools/dtrace: initial implementation of DTrace

On Thu, Jul 04, 2019 at 03:03:36PM +0200, Peter Zijlstra wrote: > On Wed, Jul 03, 2019 at 08:14:30PM -0700, Kris Van Hees wrote: > > +/* > > + * Read the data_head offset from the header page of the ring buffer. The > > + * argument is declared 'volatile' becaus

Re: [PATCH 1/1] tools/dtrace: initial implementation of DTrace

On Thu, Jul 04, 2019 at 03:05:09PM +0200, Peter Zijlstra wrote: > On Wed, Jul 03, 2019 at 08:14:30PM -0700, Kris Van Hees wrote: > > +int dt_bpf_attach(int event_id, int bpf_fd) > > +{ > > + int event_fd; > > + int rc; >

[PATCH 1/1] tools/dtrace: initial implementation of DTrace

e its only dependency (libbpf) is in the kernel tree under tools/lib/bpf. A simple 'make' in the tools/dtrace directory suffices. The 'dtrace' executable needs to run as root because BPF programs cannot be loaded by non-root users. Signed-off-by: Kris Van Hees Reviewed-by: Davi

[PATCH 0/1] tools/dtrace: initial implementation of DTrace

. Cheers, Kris Van Hees

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Mon, Jun 17, 2019 at 08:01:52PM -0700, Alexei Starovoitov wrote: > On Mon, Jun 17, 2019 at 6:54 PM Kris Van Hees > wrote: > > > > It is not hypothetical. The folowing example works fine: > > > > static int noinline bpf_action(void *ctx, long fd, long buf, lon

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Mon, Jun 17, 2019 at 06:32:22PM -0700, Alexei Starovoitov wrote: > On Mon, Jun 17, 2019 at 6:25 PM Kris Van Hees > wrote: > > > > On Thu, May 23, 2019 at 01:28:44PM -0700, Alexei Starovoitov wrote: > > > > << stuff skipped because it is not

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Thu, May 23, 2019 at 01:28:44PM -0700, Alexei Starovoitov wrote: << stuff skipped because it is not relevant to the technical discussion... >> > > > In particular you brought up a good point that there is a use case > > > for sharing a piece of bpf program between kprobe and tracepoint events.

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

bout the process and less about the technical details, so please > forgive me if I've ignored or changed the technical meaning of anything > below. > > On 30 May 2019, at 12:15, Kris Van Hees wrote: > > > On Thu, May 23, 2019 at 01:28:44PM -0700, Alexei Starovoitov wrote:

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Thu, May 23, 2019 at 01:28:44PM -0700, Alexei Starovoitov wrote: > On Thu, May 23, 2019 at 01:16:08AM -0400, Kris Van Hees wrote: > > On Wed, May 22, 2019 at 01:16:25PM -0700, Alexei Starovoitov wrote: > > > On Wed, May 22, 2019 at 12:12:53AM -0400, Kris Van Hees wrote: >

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Thu, May 23, 2019 at 07:08:51PM -0700, Alexei Starovoitov wrote: > On Thu, May 23, 2019 at 09:57:37PM -0400, Steven Rostedt wrote: > > On Thu, 23 May 2019 17:31:50 -0700 > > Alexei Starovoitov wrote: > > > > > > > > Now from what I'm reading, it seams that the Dtrace layer may be > > > > abst

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Thu, May 23, 2019 at 07:02:43PM -0400, Steven Rostedt wrote: > On Thu, 23 May 2019 14:13:31 -0700 > Alexei Starovoitov wrote: > > > > In DTrace, people write scripts based on UAPI-style interfaces and they > > > don't > > > have to concern themselves with e.g. knowing how to get the value of

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Thu, May 23, 2019 at 02:13:31PM -0700, Alexei Starovoitov wrote: > On Thu, May 23, 2019 at 01:46:10AM -0400, Kris Van Hees wrote: > > > > I think there is a difference between a solution and a good solution. > > Adding > > a lot of knowledge in the userspace com

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Wed, May 22, 2019 at 01:53:31PM -0700, Alexei Starovoitov wrote: > On Wed, May 22, 2019 at 01:23:27AM -0400, Kris Van Hees wrote: > > > > Userspace aside, there are various features that are not currently available > > such as retrieving the ppid of the current task, a

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Wed, May 22, 2019 at 12:55:27PM -0700, Alexei Starovoitov wrote: > On Wed, May 22, 2019 at 02:22:15PM -0400, Kris Van Hees wrote: > > On Wed, May 22, 2019 at 04:25:32PM +0200, Peter Zijlstra wrote: > > > On Tue, May 21, 2019 at 10:56:18AM -0700, Alexei Starovoitov wrote: >

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Wed, May 22, 2019 at 01:16:25PM -0700, Alexei Starovoitov wrote: > On Wed, May 22, 2019 at 12:12:53AM -0400, Kris Van Hees wrote: > > > > Could you elaborate on why you believe my patches are not adding generic > > features? I can certainly agree that the DTrace-speci

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Wed, May 22, 2019 at 04:25:32PM +0200, Peter Zijlstra wrote: > On Tue, May 21, 2019 at 10:56:18AM -0700, Alexei Starovoitov wrote: > > > and no changes are necessary in kernel/events/ring_buffer.c either. > > Let me just NAK them on the principle that I don't see them in my inbox. My apologie

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Tue, May 21, 2019 at 05:48:11PM -0400, Steven Rostedt wrote: > On Tue, 21 May 2019 14:43:26 -0700 > Alexei Starovoitov wrote: > > > Steve, > > sounds like you've missed all prior threads. > > I probably have missed them ;-) > > > The feedback was given to Kris it was very clear: > > implemen

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Tue, May 21, 2019 at 04:26:19PM -0700, Alexei Starovoitov wrote: > On Tue, May 21, 2019 at 05:36:49PM -0400, Kris Van Hees wrote: > > On Tue, May 21, 2019 at 01:55:34PM -0700, Alexei Starovoitov wrote: > > > On Tue, May 21, 2019 at 02:41:37PM -0400, Kris Van Hees wrote: >

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

On Tue, May 21, 2019 at 01:55:34PM -0700, Alexei Starovoitov wrote: > On Tue, May 21, 2019 at 02:41:37PM -0400, Kris Van Hees wrote: > > On Tue, May 21, 2019 at 10:56:18AM -0700, Alexei Starovoitov wrote: > > > On Mon, May 20, 2019 at 11:47:00PM +0000, Kris Van Hees wrote: >

Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

As suggested, I resent the patch set as replies to the cover letter post to support threaded access to the patches.

[RFC PATCH 05/11] trace: update Kconfig and Makefile to include DTrace

This commit adds the dtrace implementation in kernel/trace/dtrace to the trace Kconfig and Makefile. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- kernel/trace/Kconfig | 2 ++ kernel/trace/Makefile | 1 + 2 files changed, 3 insertions(+) diff --git a/kernel/trace/Kconfig b/kernel

[RFC PATCH 01/11] bpf: context casting for tail call

compilation when CONFIG_BPF_SYSCALL=n. Fixed casting issue on platforms with 32-bit pointers. v3: Renamed the new program type operations to be more descriptive. Added finalize_context() helper. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- include/linux/bpf.h

[RFC PATCH 02/11] bpf: add BPF_PROG_TYPE_DTRACE

BPF_PROG_TYPE_DTRACE implementation (building not enabled) 3. add the CONFIG_DTRACE option and enable compilation of the prog type implementation The reason for this sequence is to ensure that the kernel tree remains buildable between these commits. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock

[RFC PATCH 10/11] bpf: add bpf_buffer_reserve and bpf_buffer_commit

visible to userspace. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- include/uapi/linux/bpf.h | 39 ++- kernel/bpf/verifier.c | 6 +++- tools/include/uapi/linux/bpf.h| 39 ++- tools/testing/selftests

[RFC PATCH 11/11] dtrace: make use of writable buffers in BPF

size 0). Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- include/uapi/linux/dtrace.h | 4 + kernel/trace/dtrace/bpf.c | 150 tools/dtrace/dt_buffer.c| 54 + tools/dtrace/probe1_bpf.c | 47 ++- 4 files changed, 198

[RFC PATCH 09/11] bpf: mark helpers explicitly whether they may change

. This way, whenever a new helper is added that may change the content of the context, there is no need to update a hardcoded list of functions. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- include/linux/bpf.h| 1 + include/linux/filter.h | 1 - kernel/bpf/core.c | 5

[RFC PATCH 08/11] perf: add perf_output_begin_forward_in_page

ge is filled with 0s. A new function perf_output_begin_forward_in_page() is to be used to commence output that cannot cross page boundaries. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- include/linux/perf_event.h | 3 ++ kernel/events/ring_b

[RFC PATCH 06/11] dtrace: tiny userspace tool to exercise DTrace support

helper (aside from using bpf_probe_read() on an address that is derived from the current task). Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- MAINTAINERS | 1 + tools/dtrace/.gitignore | 1 + tools/dtrace/Makefile | 79 tools/dtrace/dt_bpf.c

  1   2   >