Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Alexei Starovoitov]

On Fri, Dec 18, 2015 at 03:04:00PM +0800, Wangnan (F) wrote:
> 
> >>However, linux/err.h is not a part of uapi. To make libbpf work, one has to
> >>create its
> >>own err.h.
> >Why tools/include/linux/err.h is not suitable for everyone?
> >
> >>Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(),  in libbpf itself.
> >seems odd. we already have user space err.h in tools/include.
> 
> Currently samples/bpf doesn't have an -I$(srctree)/tools/include.
> 
> I tried to add it into CFLAGS of samples/bpf. It causes other problems,

let's fix those problem then.

> What I want to do in this patchset is not only removing original libbpf.c
> and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
> available library for other userspace tools (tc for example). Switching
> samples/bpf into libbpf is the first step of this goal. From doing this
> I found and fixed some limitation, like those missed BPF map operations.
> Making libbpf.h and bpf.h available for normal userspace programs is also
> important.
> 
> Having the above goal, I think you can understand why improving
> tools/include
> is not a good idea. You don't want to force a normal userspace program setup
> a similar header environment for using libbpf. It is relatively a small
> library. So it would be good if bpf.h and libbpf.h only depend on what can
> be found in uapi.

completely agree on the goal of making libbpf to be a standalone library,
but disagree on tools/include dependency.
If you copy-paste err.h into libbpf either as-is or as LIBBPF_IS_ERR,
it's not going to be enough. Soon you'll need another macro from tools/include
and so on. imo it's much easier to include tools/include/ as part of
standalone libbpf.

Also at the time of creation of tools/lib/bpf we agreed that it's LGPL
just like tools/lib/traceevent, but I don't see any mention of it in
the libbpf source.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Daniel Borkmann]

On 12/18/2015 12:18 PM, pi3orama wrote:
...

Get it, and I remember you told me about this once.

There's another goal. When someone introduces new functions to eBPF, like
object pin added in these days, switching samples to libbpf will lead he/she
to help me improve libbpf, because if a new sample is needed, the libbpf backend
must be update correspondingly :)


Yep, that's good and makes sense.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[pi3orama]

发自我的 iPhone

> 在 2015年12月18日，下午6:57，Daniel Borkmann  写道：
> 
>> On 12/18/2015 08:04 AM, Wangnan (F) wrote:
>> ...
>> What I want to do in this patchset is not only removing original libbpf.c
>> and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
>> available library for other userspace tools (tc for example).
> 
> Having this as a possible user space library seems fine.
> 
> Only speaking for the tc case specifically here (since you mention it as
> one example), there's currently no additional value for it. The current
> loader code there is functional and partially tailored for tc's needs and
> having this together with the iproute2 repo, it allows us to easily change/
> adapt the internal code whenever needed.
> 
> The only dependency the loader code has is that the BPF syscall got compiled
> into the kernel and libelf, that's all. libelf is effectively available
> in distros for more than a decade(s?). And iproute2 is being shipped
> everywhere already as well (hence also iproute2's minimalism on library
> dependencies).
> 
> Switching that code would mean that iproute2 would then depend on libbpf
> which itself would depend on libelf, until every distro that ships iproute2
> will also ship libbpf, it will take a bit. Changes on the code would then
> need to go through libbpf first, and iproute2 would need to wait until it
> becomes available to make use of it and probably need to implement some
> compat code for the time being. Further, as both are decoupled also testing
> effort increases to make sure nothing breaks among different versions.
> 
> That said, I prefer that tc's {cls,act}_bpf front-end is shipped to users
> as it's being done already and that they can use it /now/ as-is. Don't get me
> wrong, for other tools etc coming up in future, as mentioned, offering it as a
> public library makes totally sense as not every application developer would
> want to choose writing his own loader code.
> 

Get it, and I remember you told me about this once.

There's another goal. When someone introduces new functions to eBPF, like
object pin added in these days, switching samples to libbpf will lead he/she
to help me improve libbpf, because if a new sample is needed, the libbpf backend
must be update correspondingly :)

> Cheers,
> Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Daniel Borkmann]

On 12/18/2015 08:04 AM, Wangnan (F) wrote:
...

What I want to do in this patchset is not only removing original libbpf.c
and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
available library for other userspace tools (tc for example).


Having this as a possible user space library seems fine.

Only speaking for the tc case specifically here (since you mention it as
one example), there's currently no additional value for it. The current
loader code there is functional and partially tailored for tc's needs and
having this together with the iproute2 repo, it allows us to easily change/
adapt the internal code whenever needed.

The only dependency the loader code has is that the BPF syscall got compiled
into the kernel and libelf, that's all. libelf is effectively available
in distros for more than a decade(s?). And iproute2 is being shipped
everywhere already as well (hence also iproute2's minimalism on library
dependencies).

Switching that code would mean that iproute2 would then depend on libbpf
which itself would depend on libelf, until every distro that ships iproute2
will also ship libbpf, it will take a bit. Changes on the code would then
need to go through libbpf first, and iproute2 would need to wait until it
becomes available to make use of it and probably need to implement some
compat code for the time being. Further, as both are decoupled also testing
effort increases to make sure nothing breaks among different versions.

That said, I prefer that tc's {cls,act}_bpf front-end is shipped to users
as it's being done already and that they can use it /now/ as-is. Don't get me
wrong, for other tools etc coming up in future, as mentioned, offering it as a
public library makes totally sense as not every application developer would
want to choose writing his own loader code.

Cheers,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Daniel Borkmann]

On 12/18/2015 08:04 AM, Wangnan (F) wrote:
...

What I want to do in this patchset is not only removing original libbpf.c
and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
available library for other userspace tools (tc for example).


Having this as a possible user space library seems fine.

Only speaking for the tc case specifically here (since you mention it as
one example), there's currently no additional value for it. The current
loader code there is functional and partially tailored for tc's needs and
having this together with the iproute2 repo, it allows us to easily change/
adapt the internal code whenever needed.

The only dependency the loader code has is that the BPF syscall got compiled
into the kernel and libelf, that's all. libelf is effectively available
in distros for more than a decade(s?). And iproute2 is being shipped
everywhere already as well (hence also iproute2's minimalism on library
dependencies).

Switching that code would mean that iproute2 would then depend on libbpf
which itself would depend on libelf, until every distro that ships iproute2
will also ship libbpf, it will take a bit. Changes on the code would then
need to go through libbpf first, and iproute2 would need to wait until it
becomes available to make use of it and probably need to implement some
compat code for the time being. Further, as both are decoupled also testing
effort increases to make sure nothing breaks among different versions.

That said, I prefer that tc's {cls,act}_bpf front-end is shipped to users
as it's being done already and that they can use it /now/ as-is. Don't get me
wrong, for other tools etc coming up in future, as mentioned, offering it as a
public library makes totally sense as not every application developer would
want to choose writing his own loader code.

Cheers,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[pi3orama]

发自我的 iPhone

> 在 2015年12月18日，下午6:57，Daniel Borkmann  写道：
> 
>> On 12/18/2015 08:04 AM, Wangnan (F) wrote:
>> ...
>> What I want to do in this patchset is not only removing original libbpf.c
>> and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
>> available library for other userspace tools (tc for example).
> 
> Having this as a possible user space library seems fine.
> 
> Only speaking for the tc case specifically here (since you mention it as
> one example), there's currently no additional value for it. The current
> loader code there is functional and partially tailored for tc's needs and
> having this together with the iproute2 repo, it allows us to easily change/
> adapt the internal code whenever needed.
> 
> The only dependency the loader code has is that the BPF syscall got compiled
> into the kernel and libelf, that's all. libelf is effectively available
> in distros for more than a decade(s?). And iproute2 is being shipped
> everywhere already as well (hence also iproute2's minimalism on library
> dependencies).
> 
> Switching that code would mean that iproute2 would then depend on libbpf
> which itself would depend on libelf, until every distro that ships iproute2
> will also ship libbpf, it will take a bit. Changes on the code would then
> need to go through libbpf first, and iproute2 would need to wait until it
> becomes available to make use of it and probably need to implement some
> compat code for the time being. Further, as both are decoupled also testing
> effort increases to make sure nothing breaks among different versions.
> 
> That said, I prefer that tc's {cls,act}_bpf front-end is shipped to users
> as it's being done already and that they can use it /now/ as-is. Don't get me
> wrong, for other tools etc coming up in future, as mentioned, offering it as a
> public library makes totally sense as not every application developer would
> want to choose writing his own loader code.
> 

Get it, and I remember you told me about this once.

There's another goal. When someone introduces new functions to eBPF, like
object pin added in these days, switching samples to libbpf will lead he/she
to help me improve libbpf, because if a new sample is needed, the libbpf backend
must be update correspondingly :)

> Cheers,
> Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Daniel Borkmann]

On 12/18/2015 12:18 PM, pi3orama wrote:
...

Get it, and I remember you told me about this once.

There's another goal. When someone introduces new functions to eBPF, like
object pin added in these days, switching samples to libbpf will lead he/she
to help me improve libbpf, because if a new sample is needed, the libbpf backend
must be update correspondingly :)


Yep, that's good and makes sense.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Alexei Starovoitov]

On Fri, Dec 18, 2015 at 03:04:00PM +0800, Wangnan (F) wrote:
> 
> >>However, linux/err.h is not a part of uapi. To make libbpf work, one has to
> >>create its
> >>own err.h.
> >Why tools/include/linux/err.h is not suitable for everyone?
> >
> >>Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(),  in libbpf itself.
> >seems odd. we already have user space err.h in tools/include.
> 
> Currently samples/bpf doesn't have an -I$(srctree)/tools/include.
> 
> I tried to add it into CFLAGS of samples/bpf. It causes other problems,

let's fix those problem then.

> What I want to do in this patchset is not only removing original libbpf.c
> and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
> available library for other userspace tools (tc for example). Switching
> samples/bpf into libbpf is the first step of this goal. From doing this
> I found and fixed some limitation, like those missed BPF map operations.
> Making libbpf.h and bpf.h available for normal userspace programs is also
> important.
> 
> Having the above goal, I think you can understand why improving
> tools/include
> is not a good idea. You don't want to force a normal userspace program setup
> a similar header environment for using libbpf. It is relatively a small
> library. So it would be good if bpf.h and libbpf.h only depend on what can
> be found in uapi.

completely agree on the goal of making libbpf to be a standalone library,
but disagree on tools/include dependency.
If you copy-paste err.h into libbpf either as-is or as LIBBPF_IS_ERR,
it's not going to be enough. Soon you'll need another macro from tools/include
and so on. imo it's much easier to include tools/include/ as part of
standalone libbpf.

Also at the time of creation of tools/lib/bpf we agreed that it's LGPL
just like tools/lib/traceevent, but I don't see any mention of it in
the libbpf source.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Wangnan (F)]

On 2015/12/18 15:04, Wangnan (F) wrote:



On 2015/12/18 14:19, Alexei Starovoitov wrote:

On Fri, Dec 18, 2015 at 09:47:11AM +0800, Wangnan (F) wrote:

This is a limitation in tools/lib/bpf/libbpf.h, which has a #include

in its header.

libbpf.h requires this include because its API uses ERR_PTR() to encode
error code.
For example, when calling bpf_object__open(), caller should use 
IS_ERR() to

check its
return value instead of compare with NULL, and use PTR_ERR() to retrive
error number.

However, linux/err.h is not a part of uapi. To make libbpf work, one 
has to

create its
own err.h.



[SNIP]

What about moving them into include/uapi/linux/filter.h ? Then
normal user programs like those in samples/bpf can access
them easier.

we don't want to add these macros to uapi.
Why not to add it to
tools/include/linux/filter.h
instead?


What I want to do in this patchset is not only removing original libbpf.c
and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
available library for other userspace tools (tc for example). Switching
samples/bpf into libbpf is the first step of this goal. From doing this
I found and fixed some limitation, like those missed BPF map operations.
Making libbpf.h and bpf.h available for normal userspace programs is also
important.

Having the above goal, I think you can understand why improving 
tools/include
is not a good idea. You don't want to force a normal userspace program 
setup

a similar header environment for using libbpf. It is relatively a small
library. So it would be good if bpf.h and libbpf.h only depend on what 
can

be found in uapi.



I suddenly realized that only linux/err.h causes problem. Those macros from
filter.h are never accessed by libbpf. So we can drop those filter.h by 
making

samples/bpf include from tools/include. However we still need a wrapper in
libbpf to avoid including linux/err.h.

Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Wangnan (F)]

On 2015/12/18 14:19, Alexei Starovoitov wrote:

On Fri, Dec 18, 2015 at 09:47:11AM +0800, Wangnan (F) wrote:

This is a limitation in tools/lib/bpf/libbpf.h, which has a #include

in its header.

libbpf.h requires this include because its API uses ERR_PTR() to encode
error code.
For example, when calling bpf_object__open(), caller should use IS_ERR() to
check its
return value instead of compare with NULL, and use PTR_ERR() to retrive
error number.

However, linux/err.h is not a part of uapi. To make libbpf work, one has to
create its
own err.h.

Why tools/include/linux/err.h is not suitable for everyone?


Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(),  in libbpf itself.

seems odd. we already have user space err.h in tools/include.


Currently samples/bpf doesn't have an -I$(srctree)/tools/include.

I tried to add it into CFLAGS of samples/bpf. It causes other problems,
This is what I get:

In file included from 
/home/w00229757/kernel-hydrogen/samples/bpf/sock_example.c:27:0:

/usr/include/linux/ip.h:101:2: error: unknown type name ‘__sum16’
  __sum16 check;
  ^
make[3]: *** [samples/bpf/sock_example.o] Error 1
make[2]: *** [samples/bpf/] Error 2
make[1]: *** [sub-make] Error 2
make: *** [__sub-make] Error 2

And after fixing __sum16 in linux/types.h:

  HOSTCC  samples/bpf/tracex4_user.o
  HOSTLD  samples/bpf/tracex4
  HOSTCC  samples/bpf/tracex5_user.o
/kernel/samples/bpf/tracex5_user.c: In function 
‘install_accept_all_seccomp’:
/kernel/samples/bpf/tracex5_user.c:15:21: error: array type has 
incomplete element type

  struct sock_filter filter[] = {
 ^
/kernel/samples/bpf/tracex5_user.c:16:3: warning: implicit declaration 
of function ‘BPF_STMT’ [-Wimplicit-function-declaration]

   BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW),
   ^
/kernel/samples/bpf/tracex5_user.c:18:9: error: variable ‘prog’ has 
initializer but incomplete type

  struct sock_fprog prog = {
 ^

Finally we need to add sock_filter, sock_fprog, BPF_STMT into 
tools/include/linux/filter.h.


It is okay, but different from what I really want to do. I'll discuss 
this later.

And I don't touch the setsockopt in all patches.

ok, but where is the bit that does attach to perf_event to make trace_output 
work?


I didn't change this test_bpf_perf_event() function (only the function 
name).

It creates a bpf-output perf event. This event is inserted into a
BPF_MAP_TYPE_PERF_EVENT_ARRAY by bpf_map_update_elem().

static void test_bpf_perf_event(int map_fd)
{
struct perf_event_attr attr = {
.sample_type = PERF_SAMPLE_RAW,
.type = PERF_TYPE_SOFTWARE,
.config = PERF_COUNT_SW_BPF_OUTPUT,
};
int key = 0;

pmu_fd = perf_event_open(, -1/*pid*/, 0/*cpu*/, 
-1/*group_fd*/, 0);


assert(pmu_fd >= 0);
assert(bpf_map_update_elem(map_fd, , _fd, BPF_ANY) == 0);
ioctl(pmu_fd, PERF_EVENT_IOC_ENABLE, 0);
}

And you read from this pmu_fd, get results. The logical is unchanged.




Orignally they are macros defined in linux/filter.h.

no. they were never part of offical filter.h. Only in my earlier versions
of bpf patches, but we decided to drop them before they got into net-next.


What about moving them into include/uapi/linux/filter.h ? Then
normal user programs like those in samples/bpf can access
them easier.

we don't want to add these macros to uapi.
Why not to add it to
tools/include/linux/filter.h
instead?


What I want to do in this patchset is not only removing original libbpf.c
and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
available library for other userspace tools (tc for example). Switching
samples/bpf into libbpf is the first step of this goal. From doing this
I found and fixed some limitation, like those missed BPF map operations.
Making libbpf.h and bpf.h available for normal userspace programs is also
important.

Having the above goal, I think you can understand why improving 
tools/include

is not a good idea. You don't want to force a normal userspace program setup
a similar header environment for using libbpf. It is relatively a small
library. So it would be good if bpf.h and libbpf.h only depend on what can
be found in uapi.

Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Alexei Starovoitov]

On Fri, Dec 18, 2015 at 09:47:11AM +0800, Wangnan (F) wrote:
> 
> This is a limitation in tools/lib/bpf/libbpf.h, which has a #include
> 
> in its header.
> 
> libbpf.h requires this include because its API uses ERR_PTR() to encode
> error code.
> For example, when calling bpf_object__open(), caller should use IS_ERR() to
> check its
> return value instead of compare with NULL, and use PTR_ERR() to retrive
> error number.
> 
> However, linux/err.h is not a part of uapi. To make libbpf work, one has to
> create its
> own err.h.

Why tools/include/linux/err.h is not suitable for everyone?

> Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(),  in libbpf itself.

seems odd. we already have user space err.h in tools/include.

> And I don't touch the setsockopt in all patches.

ok, but where is the bit that does attach to perf_event to make trace_output 
work?

> Orignally they are macros defined in linux/filter.h.

no. they were never part of offical filter.h. Only in my earlier versions
of bpf patches, but we decided to drop them before they got into net-next.

> What about moving them into include/uapi/linux/filter.h ? Then
> normal user programs like those in samples/bpf can access
> them easier.

we don't want to add these macros to uapi.
Why not to add it to
tools/include/linux/filter.h
instead?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Wangnan (F)]

On 2015/12/18 7:11, Alexei Starovoitov wrote:

On Thu, Dec 17, 2015 at 05:23:12AM +, Wang Nan wrote:

We are going to uses libbpf to replace old libbpf.[ch] and
bpf_load.[ch]. This is the first patch of this work. In this patch,
several macros and helpers in libbpf.[ch] and bpf_load.[ch] are
merged into utils.[ch]. utils.[ch] utilizes libbpf in tools/lib to
deal with BPF related things. They would be compiled after Makefile
changes.

Signed-off-by: Wang Nan 

...

+#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
+
+static inline void * __must_check ERR_PTR(long error_)
+{
+   return (void *) error_;
+}
+
+static inline long __must_check PTR_ERR(__force const void *ptr)
+{
+   return (long) ptr;
+}
+
+static inline bool __must_check IS_ERR(__force const void *ptr)
+{
+   return IS_ERR_VALUE((unsigned long)ptr);
+}

why copy paste this? I don't see the code that uses that.


This is a limitation in tools/lib/bpf/libbpf.h, which has a #include 


in its header.

libbpf.h requires this include because its API uses ERR_PTR() to encode 
error code.
For example, when calling bpf_object__open(), caller should use IS_ERR() 
to check its
return value instead of compare with NULL, and use PTR_ERR() to retrive 
error number.


However, linux/err.h is not a part of uapi. To make libbpf work, one has 
to create its

own err.h.

Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(),  in libbpf itself.


+   bpf_object__for_each_program(prog, obj) {
+   const char *event = bpf_program__title(prog, false);
+   int fd, err;
+
+   LIBBPF_PTR_ASSERT(event, goto errout);
+   __LIBBPF_ASSERT(fd = bpf_program__nth_fd(prog, 0),
+   >= 0,
+   goto errout);
+
+   if (strncmp(event, "kprobe/", 7) == 0)
+   err = create_kprobes(fd, event + 7, true);
+   else if (strncmp(event, "kretprobe/", 10) == 0)
+   err = create_kprobes(fd, event + 10, false);

I have a feeling that all bpf+socket, tcbpf1_kernc and trace_output_*.c
are broken, since I don't see a code that attaches programs to sockets
and to perf_event.
How did you test it?


I tested all samples (except tcbpf1_kern, because it is loaded by tc but tc
has not switched to libbpf) in my environment. They are okay for me. There's
no socket attaching code in this patchset because they are in sockex?_user.c
like this:

obj = load_bpf_file(filename);
if (!obj)
return 1;
...
prog_fd = get_prog_fd(obj, 0);
...
sock = open_raw_sock("lo");

assert(setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, _fd,
  sizeof(prog_fd)) == 0);

And I don't touch the setsockopt in all patches.


diff --git a/samples/bpf/utils.h b/samples/bpf/utils.h
new file mode 100644
index 000..5962a68
--- /dev/null
+++ b/samples/bpf/utils.h
@@ -0,0 +1,217 @@
+#ifndef __SAMPELS_UTILS_H
+#define __SAMPELS_UTILS_H
+
+#include 
+#include 
+
+/* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
+
+#define BPF_ALU64_REG(OP, DST, SRC)\
+   ((struct bpf_insn) {\
+   .code  = BPF_ALU64 | BPF_OP(OP) | BPF_X,\
+   .dst_reg = DST, \
+   .src_reg = SRC, \
+   .off   = 0, \
+   .imm   = 0 })

this probably belongs in tools/lib/bpf/bpf.h instead of samples.


Orignally they are macros defined in linux/filter.h. We have 3
filter.h in kernel tree:

include/linux/filter.h
include/uapi/linux/filter.h
tools/include/linux/filter.h

These macros belong to include/linux/filter.h, not part of uapi,
so we have to do things like what we have done for
tools/include/linux/filter.h.

What about moving them into include/uapi/linux/filter.h ? Then
normal user programs like those in samples/bpf can access
them easier.


The whole set depends on changes in perf/core tree, but
in net-next we have extra commit 30b50aa612018, so I don't see an easy way
to route this patch without creating across-tree merge conflicts during
merge window.
I'd suggest to apply all required work to tools/lib/bpf/ into perf/core
and leave samples/bpf/ after merge window.

Good suggestion.

I'll resend them after the PowerPC building breakage fixing is
collected.

Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Alexei Starovoitov]

On Thu, Dec 17, 2015 at 05:23:12AM +, Wang Nan wrote:
> We are going to uses libbpf to replace old libbpf.[ch] and
> bpf_load.[ch]. This is the first patch of this work. In this patch,
> several macros and helpers in libbpf.[ch] and bpf_load.[ch] are
> merged into utils.[ch]. utils.[ch] utilizes libbpf in tools/lib to
> deal with BPF related things. They would be compiled after Makefile
> changes.
> 
> Signed-off-by: Wang Nan 
...
> +#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
> +
> +static inline void * __must_check ERR_PTR(long error_)
> +{
> + return (void *) error_;
> +}
> +
> +static inline long __must_check PTR_ERR(__force const void *ptr)
> +{
> + return (long) ptr;
> +}
> +
> +static inline bool __must_check IS_ERR(__force const void *ptr)
> +{
> + return IS_ERR_VALUE((unsigned long)ptr);
> +}

why copy paste this? I don't see the code that uses that.

> + bpf_object__for_each_program(prog, obj) {
> + const char *event = bpf_program__title(prog, false);
> + int fd, err;
> +
> + LIBBPF_PTR_ASSERT(event, goto errout);
> + __LIBBPF_ASSERT(fd = bpf_program__nth_fd(prog, 0),
> + >= 0,
> + goto errout);
> +
> + if (strncmp(event, "kprobe/", 7) == 0)
> + err = create_kprobes(fd, event + 7, true);
> + else if (strncmp(event, "kretprobe/", 10) == 0)
> + err = create_kprobes(fd, event + 10, false);

I have a feeling that all bpf+socket, tcbpf1_kernc and trace_output_*.c
are broken, since I don't see a code that attaches programs to sockets
and to perf_event.
How did you test it?

> diff --git a/samples/bpf/utils.h b/samples/bpf/utils.h
> new file mode 100644
> index 000..5962a68
> --- /dev/null
> +++ b/samples/bpf/utils.h
> @@ -0,0 +1,217 @@
> +#ifndef __SAMPELS_UTILS_H
> +#define __SAMPELS_UTILS_H
> +
> +#include 
> +#include 
> +
> +/* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
> +
> +#define BPF_ALU64_REG(OP, DST, SRC)  \
> + ((struct bpf_insn) {\
> + .code  = BPF_ALU64 | BPF_OP(OP) | BPF_X,\
> + .dst_reg = DST, \
> + .src_reg = SRC, \
> + .off   = 0, \
> + .imm   = 0 })

this probably belongs in tools/lib/bpf/bpf.h instead of samples.

The whole set depends on changes in perf/core tree, but
in net-next we have extra commit 30b50aa612018, so I don't see an easy way
to route this patch without creating across-tree merge conflicts during
merge window.
I'd suggest to apply all required work to tools/lib/bpf/ into perf/core
and leave samples/bpf/ after merge window.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Alexei Starovoitov]

On Fri, Dec 18, 2015 at 09:47:11AM +0800, Wangnan (F) wrote:
> 
> This is a limitation in tools/lib/bpf/libbpf.h, which has a #include
> 
> in its header.
> 
> libbpf.h requires this include because its API uses ERR_PTR() to encode
> error code.
> For example, when calling bpf_object__open(), caller should use IS_ERR() to
> check its
> return value instead of compare with NULL, and use PTR_ERR() to retrive
> error number.
> 
> However, linux/err.h is not a part of uapi. To make libbpf work, one has to
> create its
> own err.h.

Why tools/include/linux/err.h is not suitable for everyone?

> Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(),  in libbpf itself.

seems odd. we already have user space err.h in tools/include.

> And I don't touch the setsockopt in all patches.

ok, but where is the bit that does attach to perf_event to make trace_output 
work?

> Orignally they are macros defined in linux/filter.h.

no. they were never part of offical filter.h. Only in my earlier versions
of bpf patches, but we decided to drop them before they got into net-next.

> What about moving them into include/uapi/linux/filter.h ? Then
> normal user programs like those in samples/bpf can access
> them easier.

we don't want to add these macros to uapi.
Why not to add it to
tools/include/linux/filter.h
instead?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Wangnan (F)]

On 2015/12/18 14:19, Alexei Starovoitov wrote:

On Fri, Dec 18, 2015 at 09:47:11AM +0800, Wangnan (F) wrote:

This is a limitation in tools/lib/bpf/libbpf.h, which has a #include

in its header.

libbpf.h requires this include because its API uses ERR_PTR() to encode
error code.
For example, when calling bpf_object__open(), caller should use IS_ERR() to
check its
return value instead of compare with NULL, and use PTR_ERR() to retrive
error number.

However, linux/err.h is not a part of uapi. To make libbpf work, one has to
create its
own err.h.

Why tools/include/linux/err.h is not suitable for everyone?


Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(),  in libbpf itself.

seems odd. we already have user space err.h in tools/include.


Currently samples/bpf doesn't have an -I$(srctree)/tools/include.

I tried to add it into CFLAGS of samples/bpf. It causes other problems,
This is what I get:

In file included from 
/home/w00229757/kernel-hydrogen/samples/bpf/sock_example.c:27:0:

/usr/include/linux/ip.h:101:2: error: unknown type name ‘__sum16’
  __sum16 check;
  ^
make[3]: *** [samples/bpf/sock_example.o] Error 1
make[2]: *** [samples/bpf/] Error 2
make[1]: *** [sub-make] Error 2
make: *** [__sub-make] Error 2

And after fixing __sum16 in linux/types.h:

  HOSTCC  samples/bpf/tracex4_user.o
  HOSTLD  samples/bpf/tracex4
  HOSTCC  samples/bpf/tracex5_user.o
/kernel/samples/bpf/tracex5_user.c: In function 
‘install_accept_all_seccomp’:
/kernel/samples/bpf/tracex5_user.c:15:21: error: array type has 
incomplete element type

  struct sock_filter filter[] = {
 ^
/kernel/samples/bpf/tracex5_user.c:16:3: warning: implicit declaration 
of function ‘BPF_STMT’ [-Wimplicit-function-declaration]

   BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW),
   ^
/kernel/samples/bpf/tracex5_user.c:18:9: error: variable ‘prog’ has 
initializer but incomplete type

  struct sock_fprog prog = {
 ^

Finally we need to add sock_filter, sock_fprog, BPF_STMT into 
tools/include/linux/filter.h.


It is okay, but different from what I really want to do. I'll discuss 
this later.

And I don't touch the setsockopt in all patches.

ok, but where is the bit that does attach to perf_event to make trace_output 
work?


I didn't change this test_bpf_perf_event() function (only the function 
name).

It creates a bpf-output perf event. This event is inserted into a
BPF_MAP_TYPE_PERF_EVENT_ARRAY by bpf_map_update_elem().

static void test_bpf_perf_event(int map_fd)
{
struct perf_event_attr attr = {
.sample_type = PERF_SAMPLE_RAW,
.type = PERF_TYPE_SOFTWARE,
.config = PERF_COUNT_SW_BPF_OUTPUT,
};
int key = 0;

pmu_fd = perf_event_open(, -1/*pid*/, 0/*cpu*/, 
-1/*group_fd*/, 0);


assert(pmu_fd >= 0);
assert(bpf_map_update_elem(map_fd, , _fd, BPF_ANY) == 0);
ioctl(pmu_fd, PERF_EVENT_IOC_ENABLE, 0);
}

And you read from this pmu_fd, get results. The logical is unchanged.




Orignally they are macros defined in linux/filter.h.

no. they were never part of offical filter.h. Only in my earlier versions
of bpf patches, but we decided to drop them before they got into net-next.


What about moving them into include/uapi/linux/filter.h ? Then
normal user programs like those in samples/bpf can access
them easier.

we don't want to add these macros to uapi.
Why not to add it to
tools/include/linux/filter.h
instead?


What I want to do in this patchset is not only removing original libbpf.c
and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
available library for other userspace tools (tc for example). Switching
samples/bpf into libbpf is the first step of this goal. From doing this
I found and fixed some limitation, like those missed BPF map operations.
Making libbpf.h and bpf.h available for normal userspace programs is also
important.

Having the above goal, I think you can understand why improving 
tools/include

is not a good idea. You don't want to force a normal userspace program setup
a similar header environment for using libbpf. It is relatively a small
library. So it would be good if bpf.h and libbpf.h only depend on what can
be found in uapi.

Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Wangnan (F)]

On 2015/12/18 15:04, Wangnan (F) wrote:



On 2015/12/18 14:19, Alexei Starovoitov wrote:

On Fri, Dec 18, 2015 at 09:47:11AM +0800, Wangnan (F) wrote:

This is a limitation in tools/lib/bpf/libbpf.h, which has a #include

in its header.

libbpf.h requires this include because its API uses ERR_PTR() to encode
error code.
For example, when calling bpf_object__open(), caller should use 
IS_ERR() to

check its
return value instead of compare with NULL, and use PTR_ERR() to retrive
error number.

However, linux/err.h is not a part of uapi. To make libbpf work, one 
has to

create its
own err.h.



[SNIP]

What about moving them into include/uapi/linux/filter.h ? Then
normal user programs like those in samples/bpf can access
them easier.

we don't want to add these macros to uapi.
Why not to add it to
tools/include/linux/filter.h
instead?


What I want to do in this patchset is not only removing original libbpf.c
and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
available library for other userspace tools (tc for example). Switching
samples/bpf into libbpf is the first step of this goal. From doing this
I found and fixed some limitation, like those missed BPF map operations.
Making libbpf.h and bpf.h available for normal userspace programs is also
important.

Having the above goal, I think you can understand why improving 
tools/include
is not a good idea. You don't want to force a normal userspace program 
setup

a similar header environment for using libbpf. It is relatively a small
library. So it would be good if bpf.h and libbpf.h only depend on what 
can

be found in uapi.



I suddenly realized that only linux/err.h causes problem. Those macros from
filter.h are never accessed by libbpf. So we can drop those filter.h by 
making

samples/bpf include from tools/include. However we still need a wrapper in
libbpf to avoid including linux/err.h.

Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Alexei Starovoitov]

On Thu, Dec 17, 2015 at 05:23:12AM +, Wang Nan wrote:
> We are going to uses libbpf to replace old libbpf.[ch] and
> bpf_load.[ch]. This is the first patch of this work. In this patch,
> several macros and helpers in libbpf.[ch] and bpf_load.[ch] are
> merged into utils.[ch]. utils.[ch] utilizes libbpf in tools/lib to
> deal with BPF related things. They would be compiled after Makefile
> changes.
> 
> Signed-off-by: Wang Nan 
...
> +#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
> +
> +static inline void * __must_check ERR_PTR(long error_)
> +{
> + return (void *) error_;
> +}
> +
> +static inline long __must_check PTR_ERR(__force const void *ptr)
> +{
> + return (long) ptr;
> +}
> +
> +static inline bool __must_check IS_ERR(__force const void *ptr)
> +{
> + return IS_ERR_VALUE((unsigned long)ptr);
> +}

why copy paste this? I don't see the code that uses that.

> + bpf_object__for_each_program(prog, obj) {
> + const char *event = bpf_program__title(prog, false);
> + int fd, err;
> +
> + LIBBPF_PTR_ASSERT(event, goto errout);
> + __LIBBPF_ASSERT(fd = bpf_program__nth_fd(prog, 0),
> + >= 0,
> + goto errout);
> +
> + if (strncmp(event, "kprobe/", 7) == 0)
> + err = create_kprobes(fd, event + 7, true);
> + else if (strncmp(event, "kretprobe/", 10) == 0)
> + err = create_kprobes(fd, event + 10, false);

I have a feeling that all bpf+socket, tcbpf1_kernc and trace_output_*.c
are broken, since I don't see a code that attaches programs to sockets
and to perf_event.
How did you test it?

> diff --git a/samples/bpf/utils.h b/samples/bpf/utils.h
> new file mode 100644
> index 000..5962a68
> --- /dev/null
> +++ b/samples/bpf/utils.h
> @@ -0,0 +1,217 @@
> +#ifndef __SAMPELS_UTILS_H
> +#define __SAMPELS_UTILS_H
> +
> +#include 
> +#include 
> +
> +/* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
> +
> +#define BPF_ALU64_REG(OP, DST, SRC)  \
> + ((struct bpf_insn) {\
> + .code  = BPF_ALU64 | BPF_OP(OP) | BPF_X,\
> + .dst_reg = DST, \
> + .src_reg = SRC, \
> + .off   = 0, \
> + .imm   = 0 })

this probably belongs in tools/lib/bpf/bpf.h instead of samples.

The whole set depends on changes in perf/core tree, but
in net-next we have extra commit 30b50aa612018, so I don't see an easy way
to route this patch without creating across-tree merge conflicts during
merge window.
I'd suggest to apply all required work to tools/lib/bpf/ into perf/core
and leave samples/bpf/ after merge window.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Wangnan (F)]

On 2015/12/18 7:11, Alexei Starovoitov wrote:

On Thu, Dec 17, 2015 at 05:23:12AM +, Wang Nan wrote:

We are going to uses libbpf to replace old libbpf.[ch] and
bpf_load.[ch]. This is the first patch of this work. In this patch,
several macros and helpers in libbpf.[ch] and bpf_load.[ch] are
merged into utils.[ch]. utils.[ch] utilizes libbpf in tools/lib to
deal with BPF related things. They would be compiled after Makefile
changes.

Signed-off-by: Wang Nan 

...

+#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
+
+static inline void * __must_check ERR_PTR(long error_)
+{
+   return (void *) error_;
+}
+
+static inline long __must_check PTR_ERR(__force const void *ptr)
+{
+   return (long) ptr;
+}
+
+static inline bool __must_check IS_ERR(__force const void *ptr)
+{
+   return IS_ERR_VALUE((unsigned long)ptr);
+}

why copy paste this? I don't see the code that uses that.


This is a limitation in tools/lib/bpf/libbpf.h, which has a #include 


in its header.

libbpf.h requires this include because its API uses ERR_PTR() to encode 
error code.
For example, when calling bpf_object__open(), caller should use IS_ERR() 
to check its
return value instead of compare with NULL, and use PTR_ERR() to retrive 
error number.


However, linux/err.h is not a part of uapi. To make libbpf work, one has 
to create its

own err.h.

Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(),  in libbpf itself.


+   bpf_object__for_each_program(prog, obj) {
+   const char *event = bpf_program__title(prog, false);
+   int fd, err;
+
+   LIBBPF_PTR_ASSERT(event, goto errout);
+   __LIBBPF_ASSERT(fd = bpf_program__nth_fd(prog, 0),
+   >= 0,
+   goto errout);
+
+   if (strncmp(event, "kprobe/", 7) == 0)
+   err = create_kprobes(fd, event + 7, true);
+   else if (strncmp(event, "kretprobe/", 10) == 0)
+   err = create_kprobes(fd, event + 10, false);

I have a feeling that all bpf+socket, tcbpf1_kernc and trace_output_*.c
are broken, since I don't see a code that attaches programs to sockets
and to perf_event.
How did you test it?


I tested all samples (except tcbpf1_kern, because it is loaded by tc but tc
has not switched to libbpf) in my environment. They are okay for me. There's
no socket attaching code in this patchset because they are in sockex?_user.c
like this:

obj = load_bpf_file(filename);
if (!obj)
return 1;
...
prog_fd = get_prog_fd(obj, 0);
...
sock = open_raw_sock("lo");

assert(setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, _fd,
  sizeof(prog_fd)) == 0);

And I don't touch the setsockopt in all patches.


diff --git a/samples/bpf/utils.h b/samples/bpf/utils.h
new file mode 100644
index 000..5962a68
--- /dev/null
+++ b/samples/bpf/utils.h
@@ -0,0 +1,217 @@
+#ifndef __SAMPELS_UTILS_H
+#define __SAMPELS_UTILS_H
+
+#include 
+#include 
+
+/* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
+
+#define BPF_ALU64_REG(OP, DST, SRC)\
+   ((struct bpf_insn) {\
+   .code  = BPF_ALU64 | BPF_OP(OP) | BPF_X,\
+   .dst_reg = DST, \
+   .src_reg = SRC, \
+   .off   = 0, \
+   .imm   = 0 })

this probably belongs in tools/lib/bpf/bpf.h instead of samples.


Orignally they are macros defined in linux/filter.h. We have 3
filter.h in kernel tree:

include/linux/filter.h
include/uapi/linux/filter.h
tools/include/linux/filter.h

These macros belong to include/linux/filter.h, not part of uapi,
so we have to do things like what we have done for
tools/include/linux/filter.h.

What about moving them into include/uapi/linux/filter.h ? Then
normal user programs like those in samples/bpf can access
them easier.


The whole set depends on changes in perf/core tree, but
in net-next we have extra commit 30b50aa612018, so I don't see an easy way
to route this patch without creating across-tree merge conflicts during
merge window.
I'd suggest to apply all required work to tools/lib/bpf/ into perf/core
and leave samples/bpf/ after merge window.

Good suggestion.

I'll resend them after the PowerPC building breakage fixing is
collected.

Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Wang Nan]

We are going to uses libbpf to replace old libbpf.[ch] and
bpf_load.[ch]. This is the first patch of this work. In this patch,
several macros and helpers in libbpf.[ch] and bpf_load.[ch] are
merged into utils.[ch]. utils.[ch] utilizes libbpf in tools/lib to
deal with BPF related things. They would be compiled after Makefile
changes.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Alex Gartrell 
Cc: Arnaldo Carvalho de Melo 
Cc: Brenden Blanco 
Cc: Daniel Borkmann 
Cc: Daniel Wagner 
Cc: David S. Miller 
Cc: Ingo Molnar 
Cc: Kaixu Xia 
Cc: Michael Holzheu 
Cc: Yang Shi 
---
 samples/bpf/include/linux/err.h |  56 
 samples/bpf/utils.c | 276 
 samples/bpf/utils.h | 217 +++
 3 files changed, 549 insertions(+)
 create mode 100644 samples/bpf/include/linux/err.h
 create mode 100644 samples/bpf/utils.c
 create mode 100644 samples/bpf/utils.h

diff --git a/samples/bpf/include/linux/err.h b/samples/bpf/include/linux/err.h
new file mode 100644
index 000..671b874
--- /dev/null
+++ b/samples/bpf/include/linux/err.h
@@ -0,0 +1,56 @@
+#ifndef __TOOLS_LINUX_ERR_H
+#define __TOOLS_LINUX_ERR_H
+
+#include 
+
+#ifndef __must_check
+# define __must_check
+#endif
+#ifndef __force
+# define __force
+#endif
+#ifndef unlikely
+# define unlikely(x) x
+#endif
+
+/*
+ * Original kernel header comment:
+ *
+ * Kernel pointers have redundant information, so we can use a
+ * scheme where we can return either an error code or a normal
+ * pointer with the same return value.
+ *
+ * This should be a per-architecture thing, to allow different
+ * error and pointer decisions.
+ *
+ * Userspace note:
+ * The same principle works for userspace, because 'error' pointers
+ * fall down to the unused hole far from user space, as described
+ * in Documentation/x86/x86_64/mm.txt for x86_64 arch:
+ *
+ *  - 7fff (=47 bits) user space, different per mm 
hole caused by [48:63] sign extension
+ * ffe0 -  (=2 MB) unused hole
+ *
+ * It should be the same case for other architectures, because
+ * this code is used in generic kernel code.
+ */
+#define MAX_ERRNO  4095
+
+#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
+
+static inline void * __must_check ERR_PTR(long error_)
+{
+   return (void *) error_;
+}
+
+static inline long __must_check PTR_ERR(__force const void *ptr)
+{
+   return (long) ptr;
+}
+
+static inline bool __must_check IS_ERR(__force const void *ptr)
+{
+   return IS_ERR_VALUE((unsigned long)ptr);
+}
+
+#endif /* _LINUX_ERR_H */
diff --git a/samples/bpf/utils.c b/samples/bpf/utils.c
new file mode 100644
index 000..73262a9
--- /dev/null
+++ b/samples/bpf/utils.c
@@ -0,0 +1,276 @@
+/* eBPF mini library */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "utils.h"
+
+#define DEBUGFS "/sys/kernel/debug/tracing/"
+
+int open_raw_sock(const char *name)
+{
+   struct sockaddr_ll sll;
+   int sock;
+
+   sock = socket(PF_PACKET, SOCK_RAW | SOCK_NONBLOCK | SOCK_CLOEXEC, 
htons(ETH_P_ALL));
+   if (sock < 0) {
+   printf("cannot create raw socket\n");
+   return -1;
+   }
+
+   memset(, 0, sizeof(sll));
+   sll.sll_family = AF_PACKET;
+   sll.sll_ifindex = if_nametoindex(name);
+   sll.sll_protocol = htons(ETH_P_ALL);
+   if (bind(sock, (struct sockaddr *), sizeof(sll)) < 0) {
+   printf("bind to %s: %s\n", name, strerror(errno));
+   close(sock);
+   return -1;
+   }
+
+   return sock;
+}
+
+void read_trace_pipe(void)
+{
+   int trace_fd;
+
+   trace_fd = open(DEBUGFS "trace_pipe", O_RDONLY, 0);
+   if (trace_fd < 0)
+   return;
+
+   while (1) {
+   static char buf[4096];
+   ssize_t sz;
+
+   sz = read(trace_fd, buf, sizeof(buf));
+   if (sz > 0) {
+   buf[sz] = 0;
+   puts(buf);
+   }
+   }
+}
+
+int perf_event_open(struct perf_event_attr *attr, int pid, int cpu,
+   int group_fd, unsigned long flags)
+{
+   return syscall(__NR_perf_event_open, attr, pid, cpu,
+  group_fd, flags);
+}
+
+static int prog_load_prep(struct bpf_program *prog, int n,
+ struct bpf_insn *insns, int insns_cnt,
+ struct bpf_prog_prep_result *res)
+{
+   enum bpf_prog_type prog_type;
+   int is_socket, is_kprobe, is_kretprobe;
+   const char *event = bpf_program__title(prog, false);
+
+   LIBBPF_PTR_ASSERT(event, return -1);
+
+   is_socket = strncmp(event, "socket", 6) == 0;
+   is_kprobe = strncmp(event, "kprobe/", 7) == 0;
+   is_kretprobe = strncmp(event, "kretprobe/", 10) == 0;

[PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Wang Nan]

We are going to uses libbpf to replace old libbpf.[ch] and
bpf_load.[ch]. This is the first patch of this work. In this patch,
several macros and helpers in libbpf.[ch] and bpf_load.[ch] are
merged into utils.[ch]. utils.[ch] utilizes libbpf in tools/lib to
deal with BPF related things. They would be compiled after Makefile
changes.

Signed-off-by: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Alex Gartrell 
Cc: Arnaldo Carvalho de Melo 
Cc: Brenden Blanco 
Cc: Daniel Borkmann 
Cc: Daniel Wagner 
Cc: David S. Miller 
Cc: Ingo Molnar 
Cc: Kaixu Xia 
Cc: Michael Holzheu 
Cc: Yang Shi 
---
 samples/bpf/include/linux/err.h |  56 
 samples/bpf/utils.c | 276 
 samples/bpf/utils.h | 217 +++
 3 files changed, 549 insertions(+)
 create mode 100644 samples/bpf/include/linux/err.h
 create mode 100644 samples/bpf/utils.c
 create mode 100644 samples/bpf/utils.h

diff --git a/samples/bpf/include/linux/err.h b/samples/bpf/include/linux/err.h
new file mode 100644
index 000..671b874
--- /dev/null
+++ b/samples/bpf/include/linux/err.h
@@ -0,0 +1,56 @@
+#ifndef __TOOLS_LINUX_ERR_H
+#define __TOOLS_LINUX_ERR_H
+
+#include 
+
+#ifndef __must_check
+# define __must_check
+#endif
+#ifndef __force
+# define __force
+#endif
+#ifndef unlikely
+# define unlikely(x) x
+#endif
+
+/*
+ * Original kernel header comment:
+ *
+ * Kernel pointers have redundant information, so we can use a
+ * scheme where we can return either an error code or a normal
+ * pointer with the same return value.
+ *
+ * This should be a per-architecture thing, to allow different
+ * error and pointer decisions.
+ *
+ * Userspace note:
+ * The same principle works for userspace, because 'error' pointers
+ * fall down to the unused hole far from user space, as described
+ * in Documentation/x86/x86_64/mm.txt for x86_64 arch:
+ *
+ *  - 7fff (=47 bits) user space, different per mm 
hole caused by [48:63] sign extension
+ * ffe0 -  (=2 MB) unused hole
+ *
+ * It should be the same case for other architectures, because
+ * this code is used in generic kernel code.
+ */
+#define MAX_ERRNO  4095
+
+#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
+
+static inline void * __must_check ERR_PTR(long error_)
+{
+   return (void *) error_;
+}
+
+static inline long __must_check PTR_ERR(__force const void *ptr)
+{
+   return (long) ptr;
+}
+
+static inline bool __must_check IS_ERR(__force const void *ptr)
+{
+   return IS_ERR_VALUE((unsigned long)ptr);
+}
+
+#endif /* _LINUX_ERR_H */
diff --git a/samples/bpf/utils.c b/samples/bpf/utils.c
new file mode 100644
index 000..73262a9
--- /dev/null
+++ b/samples/bpf/utils.c
@@ -0,0 +1,276 @@
+/* eBPF mini library */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "utils.h"
+
+#define DEBUGFS "/sys/kernel/debug/tracing/"
+
+int open_raw_sock(const char *name)
+{
+   struct sockaddr_ll sll;
+   int sock;
+
+   sock = socket(PF_PACKET, SOCK_RAW | SOCK_NONBLOCK | SOCK_CLOEXEC, 
htons(ETH_P_ALL));
+   if (sock < 0) {
+   printf("cannot create raw socket\n");
+   return -1;
+   }
+
+   memset(, 0, sizeof(sll));
+   sll.sll_family = AF_PACKET;
+   sll.sll_ifindex = if_nametoindex(name);
+   sll.sll_protocol = htons(ETH_P_ALL);
+   if (bind(sock, (struct sockaddr *), sizeof(sll)) < 0) {
+   printf("bind to %s: %s\n", name, strerror(errno));
+   close(sock);
+   return -1;
+   }
+
+   return sock;
+}
+
+void read_trace_pipe(void)
+{
+   int trace_fd;
+
+   trace_fd = open(DEBUGFS "trace_pipe", O_RDONLY, 0);
+   if (trace_fd < 0)
+   return;
+
+   while (1) {
+   static char buf[4096];
+   ssize_t sz;
+
+   sz = read(trace_fd, buf, sizeof(buf));
+   if (sz > 0) {
+   buf[sz] = 0;
+   puts(buf);
+   }
+   }
+}
+
+int perf_event_open(struct perf_event_attr *attr, int pid, int cpu,
+   int group_fd, unsigned long flags)
+{
+   return syscall(__NR_perf_event_open, attr, pid, cpu,
+  group_fd, flags);
+}
+
+static int prog_load_prep(struct bpf_program *prog, int n,
+ struct bpf_insn *insns, int insns_cnt,
+ struct bpf_prog_prep_result *res)
+{
+   enum bpf_prog_type prog_type;
+   int is_socket, is_kprobe, is_kretprobe;
+   const char *event