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
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
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
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
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
$(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
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
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
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
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
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 |
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
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
/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
.
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 map
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
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
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
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
---
scripts/generate_builtin_ranges.awk | 149
1 file changed, 149 insertions(+)
create mode 100755
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
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
/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
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.
Kris Van
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 principles beh
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 sa
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 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
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 [-lvV] [
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: David Mc Lean
Reviewed-by: Eugene
/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
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
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' because it refer
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;
>
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: David Mc Lean
Reviewed-by: Eugene
.
Cheers,
Kris Van Hees
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
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
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
out 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:
>
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:
>
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
> > > >
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
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
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
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
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 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
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:
> >
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 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:
>
As suggested, I resent the patch set as replies to the cover letter post
to support threaded access to the patches.
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
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
the 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
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
(and 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
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_buffer.c | 65 -
2 files changed
of a 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
l(ctx, , 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 mailing list for
specific development discussio
ers 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, 145 inserti
(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
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
. 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
> > number of writable
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
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_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
(and 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
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
the 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
l(ctx, , 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 mailing list for
specific development discussio
of a 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
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_buffer.c | 65 -
2 files changed
. 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
ers 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, 145 inserti
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
76 matches
Mail list logo
