All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Alexei Starovoitov <ast@plumgrid.com>,
	Ingo Molnar <mingo@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Jiri Olsa <jolsa@redhat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Linux API <linux-api@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	ebiederm@xmission.com
Subject: Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
Date: Wed, 11 Feb 2015 11:28:52 +0100	[thread overview]
Message-ID: <20150211102852.GQ23123@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20150210165359.34cc53d9@gandalf.local.home>

On Tue, Feb 10, 2015 at 04:53:59PM -0500, Steven Rostedt wrote:
> > >> In the future we might add a tracepoint and pass a single
> > >> pointer to interesting data struct to it. bpf programs will walk
> > >> data structures 'as safe modules' via bpf_fetch*() methods
> > >> without exposing it as ABI.
> > >
> > > Will this work if that structure changes? When the field we are looking
> > > for no longer exists?
> > 
> > bpf_fetch*() is the same mechanism as perf probe.
> > If there is a mistake by user space tools, the program
> > will be reading some junk, but it won't be crashing.
> 
> But what if the userspace tool depends on that value returning
> something meaningful. If it was meaningful in the past, it will have to
> be meaningful in the future, even if the internals of the kernel make
> it otherwise.

We're compiling the BPF stuff against the 'current' kernel headers
right? So would enforcing module versioning not be sufficient?

We already break out-of-tree modules without a second thought, the
module interface is not guaranteed. They just need to cope with it.

Anything using the kernel headers to look into the kernel guts should be
bound to the same rules.

So if we think of BFP stuff as out-of-tree modules, and treat them the
same, I see no problem.

I'm sure some BFP 'scripts' will turn in the same right mess that
out-of-tree modules are, with endless #ifdef version checks, but hey,
not my problem ;-)

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>
Cc: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>,
	Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Namhyung Kim <namhyung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Arnaldo Carvalho de Melo
	<acme-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Jiri Olsa <jolsa-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Masami Hiramatsu
	<masami.hiramatsu.pt-FCd8Q96Dh0JBDgjK7y7TUQ@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Network Development
	<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linus Torvalds
	<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org
Subject: Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
Date: Wed, 11 Feb 2015 11:28:52 +0100	[thread overview]
Message-ID: <20150211102852.GQ23123@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20150210165359.34cc53d9-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>

On Tue, Feb 10, 2015 at 04:53:59PM -0500, Steven Rostedt wrote:
> > >> In the future we might add a tracepoint and pass a single
> > >> pointer to interesting data struct to it. bpf programs will walk
> > >> data structures 'as safe modules' via bpf_fetch*() methods
> > >> without exposing it as ABI.
> > >
> > > Will this work if that structure changes? When the field we are looking
> > > for no longer exists?
> > 
> > bpf_fetch*() is the same mechanism as perf probe.
> > If there is a mistake by user space tools, the program
> > will be reading some junk, but it won't be crashing.
> 
> But what if the userspace tool depends on that value returning
> something meaningful. If it was meaningful in the past, it will have to
> be meaningful in the future, even if the internals of the kernel make
> it otherwise.

We're compiling the BPF stuff against the 'current' kernel headers
right? So would enforcing module versioning not be sufficient?

We already break out-of-tree modules without a second thought, the
module interface is not guaranteed. They just need to cope with it.

Anything using the kernel headers to look into the kernel guts should be
bound to the same rules.

So if we think of BFP stuff as out-of-tree modules, and treat them the
same, I see no problem.

I'm sure some BFP 'scripts' will turn in the same right mess that
out-of-tree modules are, with endless #ifdef version checks, but hey,
not my problem ;-)

  reply	other threads:[~2015-02-11 10:29 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-10 19:53 [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Alexei Starovoitov
2015-02-10 21:53 ` Steven Rostedt
2015-02-10 21:53   ` Steven Rostedt
2015-02-11 10:28   ` Peter Zijlstra [this message]
2015-02-11 10:28     ` Peter Zijlstra
  -- strict thread matches above, loose matches on Subject: below --
2015-02-23 18:55 Alexei Starovoitov
2015-02-23 18:55 ` Alexei Starovoitov
2015-02-14 23:02 Alexei Starovoitov
2015-02-14 23:02 ` Alexei Starovoitov
2015-02-14 22:54 Alexei Starovoitov
2015-02-14 22:54 ` Alexei Starovoitov
2015-02-14 22:48 Alexei Starovoitov
2015-02-14 22:48 ` Alexei Starovoitov
2015-02-11  6:33 Alexei Starovoitov
2015-02-11  6:33 ` Alexei Starovoitov
2015-02-11 12:51 ` Steven Rostedt
2015-02-11 12:51   ` Steven Rostedt
2015-02-11  3:04 Alexei Starovoitov
2015-02-11  4:31 ` Steven Rostedt
2015-02-11  4:31   ` Steven Rostedt
2015-02-11  0:22 Alexei Starovoitov
2015-02-11  0:50 ` Steven Rostedt
2015-02-11  0:50   ` Steven Rostedt
2015-02-11  9:33 ` Peter Zijlstra
2015-02-11  9:45 ` Peter Zijlstra
2015-02-11  9:45   ` Peter Zijlstra
2015-02-11 10:15 ` Peter Zijlstra
2015-02-11 10:15   ` Peter Zijlstra
2015-02-12  4:58 ` Hekuang
2015-02-12  4:58   ` Hekuang
2015-02-12  4:58   ` Hekuang
2015-02-16 11:26 ` He Kuang
2015-02-16 11:26   ` He Kuang
2015-02-10  6:10 Alexei Starovoitov
2015-02-10  6:10 ` Alexei Starovoitov
2015-02-10 13:05 ` Steven Rostedt
2015-02-10 13:05   ` Steven Rostedt
2015-02-10  5:51 Alexei Starovoitov
2015-02-10  5:51 ` Alexei Starovoitov
2015-02-10 12:27 ` Steven Rostedt
2015-02-10  3:45 [PATCH v3 linux-trace 0/8] tracing: attach eBPF programs to tracepoints/syscalls/kprobe Alexei Starovoitov
2015-02-10  3:45 ` [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Alexei Starovoitov
2015-02-10  3:45   ` Alexei Starovoitov
2015-02-10  4:46   ` Steven Rostedt
2015-02-10  4:46     ` Steven Rostedt
2015-02-10  5:13   ` Steven Rostedt
2015-02-10  5:13     ` Steven Rostedt

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=20150211102852.GQ23123@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@infradead.org \
    --cc=ast@plumgrid.com \
    --cc=ebiederm@xmission.com \
    --cc=jolsa@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    /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.