On Tue, May 28, 2019 at 11:35 AM Daniel Xu <dxu@...> wrote:

I'm reading through codegen_llvm.cpp[0] and I noticed that ustack
map keys are packed with a PID. From what I understand, if you run

bpftrace -e 'uprobe:/lib64/libc.so.6:usleep /comm == "a.out"/ { @[ustack(2)] = count() }'

and a.out has forked, it would cause duplicate stack traces to be outputted.
This has caused some confusion in the past with users.

I'm wondering what the intention behind PID packing is.

The stack ID returned by ustack() points to a stack as a list of
addresses. That gets translated sometime later in user-space by
bpftrace. At that point you just have an address, and you need to know
which PID it belongs to, so you can lookup that processes's address
mappings.

If BPF one day can save the stack as a list of strings in the kernel
(meaning the kernel must support user-space symbol lookup), then we
wouldn't need the PID (this has been discussed before).

I don't know about this fork problem you mention.

Brendan

Thanks,
Daniel
---
[0]: https://github.com/iovisor/bpftrace/blob/master/src/ast/codegen_llvm.cpp#L748-L756

I'm reading through codegen_llvm.cpp[0] and I noticed that ustack
map keys are packed with a PID. From what I understand, if you run

bpftrace -e 'uprobe:/lib64/libc.so.6:usleep /comm == "a.out"/ { @[ustack(2)] = count() }'

and a.out has forked, it would cause duplicate stack traces to be outputted.
This has caused some confusion in the past with users.

I'm wondering what the intention behind PID packing is.

Thanks,
Daniel
---
[0]: https://github.com/iovisor/bpftrace/blob/master/src/ast/codegen_llvm.cpp#L748-L756

On Mon, May 27, 2019 at 4:04 AM Dorian ROSSE <dorianbrice@...> wrote:
>
> Hello everybody,
>
>
> Do you know if I can use a bpf file from bcc for snort ?

You mean a bpf program, right?
Do you mean to have a bpf program to do L7 parsing?
If simple one, it should work. See bcc/examples/networking/http_filter/*.
But since kernel verifier currently does not support loops,
the complex options may not be supported.

>
> Thank you in advance to answer if I can and how to do my ask,
>
> Regards.
>
>
> Dorian ROSSE.
>
>
>
> Provenance : Courrier pour Windows 10
>
>
>

On Mon, May 27, 2019 at 4:04 AM Dorian ROSSE <dorianbrice@...> wrote:

Hello everybody,


Do you know if I can use a bpf file from bcc for snort ?

You mean a bpf program, right?
Do you mean to have a bpf program to do L7 parsing?
If simple one, it should work. See bcc/examples/networking/http_filter/*.
But since kernel verifier currently does not support loops,
the complex options may not be supported.

Thank you in advance to answer if I can and how to do my ask,

Regards.


Dorian ROSSE.



Provenance : Courrier pour Windows 10

Thank You Daniel for your timely help!

On 05/22/2019 09:26 AM, Prashanth Fernando wrote:

Thank You, I updated clang and now I am able to compile the code in CentOS-7.

I am facing another issue while loading the ebpf code in tc. I am able to run this in Ubuntu-18.04, but the usecase is to run it in CentOS. Can someone please help me out in resolving it.
replicator.o is my objext file and classifier/action are the classifier/action code.

# sudo tc filter add dev enp0s8 parent ffff: bpf obj replicator.o sec classifier flowid ffff:1 \
action bpf obj replicator.o sec action ok
What is "obj"?
Usage: ... bpf ...

Judging from above error and that it works on Ubuntu 18.04, then your iproute2
version in CentOS-7 is simply too old aka lacking eBPF support.

Try compiling one from recent Git [0] or some more recent tarball, then it
should work provided you have a proper kernel with it.

Perhaps also [1] might help you getting started, e.g. you can use cls_bpf in
direct action mode which is much more efficient than going through ac_bpf,
see the guide for more info.

[0] https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/
[1] https://cilium.readthedocs.io/en/latest/bpf/#iproute2

[inline]:     run bytecode BPF_BYTECODE
[from file]:  run bytecode-file FILE

[ police POLICE_SPEC ] [ action ACTION_SPEC ]
[ classid CLASSID ]

Where BPF_BYTECODE := 's,c t f k,c t f k,c t f k,...'
c,t,f,k and s are decimals; s denotes number of 4-tuples
Where FILE points to a file containing the BPF_BYTECODE string

Tks,
PRashanth

Prashanth Fernando <prashanth.fernando@...> writes:

Hi,
Thanks for your response. I had a doubt that the kernel has to be upgraded.
So I upgraded the kernel to 5.1.3, still I face the issue.

You also need to compile a new version of iproute2 (where the 'tc' and
'ip' utilities come from).

-Toke

Hi, 
Thanks for your response. I had a doubt that the kernel has to be upgraded.
So I upgraded the kernel to 5.1.3, still I face the issue. 

I compiled the kernel with these options, have I missed out some option ?

On Wed, 22 May 2019 00:26:54 -0700
"Prashanth Fernando" <prashanth.fernando@...> wrote:

Thank You, I updated clang and now I am able to compile the code in
CentOS-7.

I am facing another issue while loading the ebpf code in tc. I am
able to run this in Ubuntu-18.04, but the usecase is to run it in
CentOS. Can someone please help me out in resolving it.

You have to use CentOS-8 for TC (and XDP) support, or install a newer
kernel version on CentOS-7.

--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer

https://linuxhint.com/centos8-release-date-and-features/

On Tue, 21 May 2019 23:17:28 -0700
"Yonghong Song" <ys114321@...> wrote:

bpf needs 3.7.1 and higher version. Later clang (>= 3.7.1) has more features.

In the kernel tree it is documented here:
https://github.com/torvalds/linux/blob/master/samples/bpf/README.rst

But the kernel says:
clang >= version 3.4.0 + llvm >= version 3.7.1

What is your 'llc' version?
(run command: llc --version )

On Tue, May 21, 2019 at 11:13 PM Prashanth Fernando
<prashanth.fernando@...> wrote:

Hi,

The clang version I am using is 3.4.2

clang --version
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: x86_64-redhat-linux-gnu
Thread model: posix

--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer

Thank You, I updated clang and now I am able to compile the code in CentOS-7.

I am facing another issue while loading the ebpf code in tc. I am able to run this in Ubuntu-18.04, but the usecase is to run it in CentOS. Can someone please help me out in resolving it. 
replicator.o is my objext file and classifier/action are the classifier/action code.

bpf needs 3.7.1 and higher version. Later clang (>= 3.7.1) has more features.

On Tue, May 21, 2019 at 11:13 PM Prashanth Fernando
<prashanth.fernando@...> wrote:

Hi,

The clang version I am using is 3.4.2

clang --version
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: x86_64-redhat-linux-gnu
Thread model: posix

Tks,
PRashanth

Hi, 

The clang version I am using is 3.4.2

On Wed, 22 May 2019 12:28:46 +0800
"Gary Lin" <glin@...> wrote:

On Tue, May 21, 2019 at 08:17:16PM -0700, forrest0579@... wrote:

Hi,
I’m new to bpf and when run `iovisor/bcc` examples with
`xdp_redirect_cpu.py` in my vm, the connection will lost and I have
to restart my vm. In my understanding this example just foword the
package from one cpu to another and the package should not lost. Am
I missing something? Anyone can help me? Thank you

PS: xdp is loaded in xdpgeneric mode

CPUMAP is not supported by generic XDP(*). Besides, it provides very little
benefit since the packet is already packaged into a skb and there is no need
to package it again with another CPU.

(*) https://github.com/torvalds/linux/blob/v5.1/net/core/filter.c#L3560-L3563

Thanks you Gary, for pointing this out. I added the TODO in the code,
and it is still on my todo list for CPUMAP here:

https://github.com/xdp-project/xdp-project/blob/master/areas/cpumap.org

--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer

On Tue, May 21, 2019 at 08:17:16PM -0700, forrest0579@... wrote:

Hi, I’m new to bpf and when run `iovisor/bcc` examples with `xdp_redirect_cpu.py` in my vm, the connection will lost and I have to restart my vm. In my understanding this example just foword the package from one cpu to another and the package should not lost. Am I missing something? Anyone can help me? Thank you

PS: xdp is loaded in xdpgeneric mode

CPUMAP is not supported by generic XDP(*). Besides, it provides very little
benefit since the packet is already packaged into a skb and there is no need
to package it again with another CPU.

Cheers,

Gary Lin

(*) https://github.com/torvalds/linux/blob/v5.1/net/core/filter.c#L3560-L3563

On 05/21/2019 08:42 PM, Prashanth Fernando wrote:

Hi,

I'm new to XDP, I am trying to compile a simple code to start with.
When I compile with clang, I face an error. Can someone please help me out in resolving this issue.

# clang -target bpf -c drop.c -o drop.o
error: unknown target triple 'bpf', please use -triple or -arch

Which version of clang are you using? It looks like it is missing the bpf
target.

-Tom

OS: CentOS 7
Updated Kernel:
# uname -msr
Linux 5.1.3 x86_64

Built the kernel with the following flags on:
CONFIG_CGROUP_BPF=y
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_NETFILTER_XT_MATCH_BPF=m
CONFIG_BPFILTER=y
CONFIG_BPFILTER_UMH=m
CONFIG_NET_CLS_BPF=m
CONFIG_NET_ACT_BPF=m
CONFIG_BPF_JIT=y
CONFIG_BPF_STREAM_PARSER=y
CONFIG_LWTUNNEL_BPF=y
CONFIG_HAVE_EBPF_JIT=y
CONFIG_BPF_EVENTS=y
CONFIG_BPF_KPROBE_OVERRIDE=y
CONFIG_TEST_BPF=m

I am not sure what I am missing still.

Hi, 

I'm new to XDP, I am trying to compile a simple code to start with.
When I compile with clang, I face an error. Can someone please help me out in resolving this issue.

Hi, I’m new to bpf and when run `iovisor/bcc` examples with `xdp_redirect_cpu.py` in my vm, the connection will lost and I have to restart my vm. In my understanding this example just foword the package from one cpu to another and the package should not lost. Am I missing something? Anyone can help me? Thank you

PS: xdp is loaded in xdpgeneric mode

This is a call for proposals for the BPF micro-conference at this
years' Linux Plumbers Conference (LPC) 2019 which will be held in
Lisbon, Portugal for September 9-11.

The goal of the BPF micro-conference is to bring BPF developers
together to discuss topics around Linux kernel work related to
the BPF core infrastructure as well as its many subsystems under
tracing, networking, security, and BPF user space tooling (LLVM,
libbpf, bpftool and many others).

The format of the micro-conference has a main focus on discussion,
therefore each accepted topic will provide a short 1-2 slide
introduction with subsequent discussion for the rest of the given
time slot.

The BPF micro-conference is a community-driven event and open to
all LPC attendees, there is no additional registration required.

Please submit your discussion proposals to the LPC BPF micro-conference
organizers at:

lpc-bpf@...

Proposals must be submitted until August 2nd, and submitters will
be notified of acceptance at latest by August 9. (Please note that
proposals must not be sent as html mail as they are otherwise dropped
by vger.)

The format of the submission and many other details can be found at:

http://vger.kernel.org/lpc-bpf.html

Looking forward to seeing you all in Lisbon in September!