-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
/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
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
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
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 |
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
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
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
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
$(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
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
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
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
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
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
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
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.
>
> > 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
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
/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
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
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
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
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
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
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.
&
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
>
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
$(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
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
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
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
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
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
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
.*.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
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
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
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
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
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
>
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
> > -
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
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
> >
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
-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
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:
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
.*.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
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
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
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
-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
.*.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
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
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
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
.*.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
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
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.
-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
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
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
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
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
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
.*.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
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:
> >
> > 2. bpf: add BPF_PROG_TYPE_DTRACE
> >
> > This patch adds BPF_PROG_TYPE_DTRACE as a new BPF program type, without
&g
(bpf_get_perf_event_output_proto()).
Signed-off-by: Kris Van Hees
Reviewed-by: Nick Alcock
---
include/linux/bpf.h | 1 +
kernel/trace/bpf_trace.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 7a40a3cd7ff2..e4bcb79656c4 100644
into DTRACE BPF program. */
bpf_tail_call(ctx, &progs, 1);
/* fall through -> program not found or call failed */
return 0;
}
This patch also adds DTrace as a new subsystem in the MAINTAINERS file,
with me as current maintainer and our development m
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
pointers to a buffer is
cleared, just as it is done for packet pointers.
Signed-off-by: Kris Van Hees
Reviewed-by: Nick Alcock
---
include/linux/bpf.h | 3 +
include/linux/bpf_verifier.h | 4 +-
kernel/bpf/verifier.c| 198 ---
3 files changed, 1
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
. 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
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
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
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
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
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
As suggested, I resent the patch set as replies to the cover letter post
to support threaded access to the patches.
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:
>
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:
>
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
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
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
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:
>
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
This patch set is also available, applied to bpf-next, at the following URL:
https://github.com/oracle/dtrace-linux-kernel/tree/dtrace-bpf
The patches in this set are part of an larger effort to re-implement DTrace
based on existing Linux kernel features wherever possible. This allows
ex
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
. 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
pointers to a buffer is
cleared, just as it is done for packet pointers.
Signed-off-by: Kris Van Hees
Reviewed-by: Nick Alcock
---
include/linux/bpf.h | 3 +
include/linux/bpf_verifier.h | 4 +-
kernel/bpf/verifier.c| 198 ---
3 files changed, 1
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
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
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
into DTRACE BPF program. */
bpf_tail_call(ctx, &progs, 1);
/* fall through -> program not found or call failed */
return 0;
}
This patch also adds DTrace as a new subsystem in the MAINTAINERS file,
with me as current maintainer and our development m
(bpf_get_perf_event_output_proto()).
Signed-off-by: Kris Van Hees
Reviewed-by: Nick Alcock
---
include/linux/bpf.h | 1 +
kernel/trace/bpf_trace.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 7a40a3cd7ff2..e4bcb79656c4 100644
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
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
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
for adding
him. I will update my list.
Kris
> On Mon, 20 May 2019 23:52:24 + (UTC)
> Kris Van Hees wrote:
>
> > Currently, BPF supports writes to packet data in very specific cases.
> > The implementation can be of more general use and can be extended to any
> > num
1 - 100 of 117 matches
Mail list logo
