Thread (14 messages) flat view 14 messages, 3 authors, 2015-01-29

Re: [PATCH v2 linux-trace 4/8] samples: bpf: simple tracing example in C

From: Arnaldo Carvalho de Melo <acme@kernel.org>
Date: 2015-01-28 20:44:43
Also in: lkml, netdev

Em Wed, Jan 28, 2015 at 08:42:29AM -0800, Alexei Starovoitov escreveu:
On Wed, Jan 28, 2015 at 8:25 AM, Arnaldo Carvalho de Melo
[off-list ref] wrote:
quoted
Em Wed, Jan 28, 2015 at 01:24:15PM -0300, Arnaldo Carvalho de Melo escreveu:
quoted
Em Tue, Jan 27, 2015 at 08:06:09PM -0800, Alexei Starovoitov escreveu:
quoted
+   if (bpf_memcmp(dev->name, devname, 2) == 0)
quoted
quoted
I'm only starting to look at all this, so bear with me... But why do we
need to have it as "bpf_memcmp"? Can't we simply use it as "memcmp" and
have it use the right function?
quoted
quoted
Less typing, perhaps we would need to have a:
quoted
quoted
#define memcmp bpf_memcmp(s1, s2, n) bpf_memcmp(s1, s2, n)
quoted
Argh, like this:
quoted
#define memcmp(s1, s2, n) bpf_memcmp(s1, s2, n)
quoted
quoted
in bpf_helpers.h to have it work?
yes, that will work just fine.
Since it's an example I made it explicit that bpf_memcmp()
has memcmp() semantics, but little bit different:
int bpf_memcmp(void *unsafe_ptr, void *safe_ptr, int size)
Not knowing about the safe/unsafe pointers (at this point in my
conceptual eBPF learning process), I would think that it would be easier
to understand if it would reuse another well known idiom:

#define memcmp_from_user(kernel, user, n) bpf_memcmp(user, kernel, n)

That would be similar to:

 copy_from_user(void *to, const void __user *from, unsigned long n)

But here, again bear with me, I'm just brainstorming, as from just
looking at:

  bpf_memcmp(a, b, n)

I don't reuse anything I've learned before trying to understand eBPF,
not I see any well known marker (__user) that would help me understand
that that pointer needs special treatment/belongs to a different "domain".
meaning that one of the pointers can point anywhere and
the function will be doing probe_kernel_read() underneath
similar to bpf_fetch_*() helpers.
If it was plain memcmp() it would give a wrong impression
that vanilla memcmp() can be used.
Since that is not the case, I agree that the 'memcmp' semantic can't be
used, as the two pointers are not on the same "domain", so to say.
In general the programs cannot use any library functions
outside of helpers defined in uapi/linux/bpf.h

bpf_fetch_*() helpers are also explicit in examples.
If one need to do a lot of pointer walking, then macro like
#define D(P) ((typeof(P))bpf_fetch_ptr(&P))
would be easier to use: p = D(D(skb->dev)->ifalias)
multiple pointer derefs would look more natural...
And if possible, i.e. if the eBPF compiler would take care of that
somehow, would indeed be preferred as it looks more natural :-)

- Arnaldo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help