Date   

minutes: IO Visor TSC/Dev Meeting

Brenden Blanco
 

Hi All,

Thanks for dialing in today. As usual, here are my notes.
Cheers!
-Brenden

=== Discussion ===

Brenden:
* f28 and ubuntu18.04 support
* 0.6.1 tagged with those packages
* will try to get python3 testing enabled

Yonghong:
* Catching up with some mailing list questions
* Going to try using BTF for profiling with FB internal tools
* encode source code information for bpf program into btf
* some introspection enhancements

Jiong:
* Progress on bpf llvm backend support for memcpy
* patch set is out for review
* working on better 32 bit support, llvm+verifier
* 32 bit load/store into stack
* needs better data structure in verifier for tracking <8B writes

PJ:
via email:
"""
Right now we're working on converting the work we did on HW hint providing into
the BTF format, like we discussed in the last meeting. We're making decent
progress, and should be able to share something soon to see what people think.
We're also looking at how to connect the format specification with a
communication mechanism to the drivers to program them to provide the metadata.
Both of these are ongoing.
"""

Daniel:
* Setting up list for plumbers schedule, lots of talks already submitted


=== Attendees ===
Brenden Blanco
Marco Leogrande
Jiong wang
Flavio Crisciani
Kuba Kicinski
Mauricio Vasquez
Yonghong Song
Alexander Duyck
Joe Stringer
Martin Lau
Saeed
Andy Gospodarek
Daniel Borkmann


reminder: IO Visor TSC/Dev Meeting

Brenden Blanco
 

Please join us tomorrow for our bi-weekly call. As usual, this meeting is
open to everybody and completely optional.
You might be interested to join if:
You want to know what is going on in BPF land
You are doing something interesting yourself with BPF and would like to share
You want to know what the heck BPF is

=== IO Visor Dev/TSC Meeting ===

Every 2 weeks on Wednesday, from Wednesday, January 25, 2017, to no end date
11:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 30 min

https://bluejeans.com/568677804/

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2018&month=7&day=25&hour=18&min=0&sec=0&p1=900


Re: Helper functions available for XDP?

Yonghong Song
 

On Tue, Jul 24, 2018 at 9:19 AM, Andrew Wang <andrw.wng@...> wrote:
Then in this case is it possible to replace TCP checksum on ingress with
XDP? How do I test if the skb is writable?
There is no skb in XDP. The helper bpf_l4_csum_replace cannot be used.
You need to use other csum functions and can directly modify the packet data.


On Tue, Jul 24, 2018 at 12:04 PM, Yonghong Song <ys114321@...> wrote:

On Tue, Jul 24, 2018 at 1:54 AM, François <fser@...> wrote:
On Mon, Jul 23, 2018 at 10:08:08PM +0200, Paul Chaignon wrote:
On Mon, Jul 23, 2018 at 02:21:05PM -0400, Andrew Wang wrote:
Hi

I am writing a bpf program for packet processing and have loaded my
ingress
function at BPF.XDP.

I'm updating the destination IPv6 address and want to update the TCP
checksum, but when I try to call the helper functions "bpf_csum_diff"
or
"bpf_l4_csum_replace", I get a "unknown func <function name>". Are
these
functions not available for XDP program types?
XDP programs cannot use bpf_l4_csum_replace, but they can use
bpf_csum_diff since commit 205c380 ("bpf: add csum_diff helper to xdp
as
well") which landed in v4.16-rc1.
I was thinking maybe those helpers were not available because no skb
was construct. But after checking, the helper you're mentionning is in
the tc_cls. Also, the csum_diff helper lies in the same switch
statement as l4_csum_replace.

Can you elaborate on why one can be used and not the other?
bpf_csum_diff only accesses packet data and can be used in both cls_act
and xdp.
bpf_l4_csum_replace accesses skb data structure, e.g., it needs to
replace the csum
and hence needs to test whether skb is writable. It also different
calculation based on
the existing checksum state (skb->ip_summed), so bpf_l4_csum_replace
cannot be
used in xdp.


Thanks!




Re: Fixing stack trace function names by argument introspection

Yonghong Song
 

On Tue, Jul 24, 2018 at 9:06 AM, marko@... <marko@...> wrote:


On Mon, Jul 23, 2018 at 7:48 AM, Y Song <ys114321@...> wrote:


We did not have such an example in BCC. In Facebook, we have a bpf
program to catch
stack traces for python programs. It is very similar to what you want
to achieve in the above.

Can you share it with me? Maybe I can use it as an example.
It is a piece of complicated software, let me see how much I can do.



Basically, you need to walk the stack by yourself. Since verifier do
not support unbounded loops,
you need to have a fully-unrollable loop with progma unroll.

I have never used pragma unroll before, but I understand what it is supposed
to do.
Quick search gives me usages for CUDA and several little known examples for
gcc/clang.
Are you talking about them?
https://stackoverflow.com/questions/4071690/tell-gcc-to-specifically-unroll-a-loop
Yes, it is `#pragma unroll`.



During each loop iteration, you can access the frame pointer, you need
some mechanism to
get the real function name based on that level frame pointer and then
you move on
to the next. In bpf program, you can access current task structure,
which contains some
data related to TLS which could be used by the bpf program.
As far as I understand it would work if my program is built with frame
pointers. In that case going throigh stack trace shold be straightforward.
Never done it before though :-)
Not 100% whether just frame pointers are enough for you or not.
Remeber, on the stack, typically only frame pointer (if available),
function return address, spills, and #7 and later arguments.
It is very likely the case that `fn_name` in `execute_fn(fn_name)` may
not on the stack and you need to find a different way to access it.

But usually programs are build omitting frame pointers. In that case you
need additional info from DWARF and code is much more complex. Right?
Are you suggesting implementing all this?
We are talking about stack walking inside bpf programs, dwarf option is
certainly out of question. In that case, you may need to use
perf record dwarf...


Sorry for newbie questions :-)


Re: Helper functions available for XDP?

Andrew Wang
 

Then in this case is it possible to replace TCP checksum on ingress with XDP? How do I test if the skb is writable?

On Tue, Jul 24, 2018 at 12:04 PM, Yonghong Song <ys114321@...> wrote:
On Tue, Jul 24, 2018 at 1:54 AM, François <fser@...> wrote:
> On Mon, Jul 23, 2018 at 10:08:08PM +0200, Paul Chaignon wrote:
>> On Mon, Jul 23, 2018 at 02:21:05PM -0400, Andrew Wang wrote:
>> > Hi
>> >
>> > I am writing a bpf program for packet processing and have loaded my ingress
>> > function at BPF.XDP.
>> >
>> > I'm updating the destination IPv6 address and want to update the TCP
>> > checksum, but when I try to call the helper functions "bpf_csum_diff" or
>> > "bpf_l4_csum_replace", I get a "unknown func <function name>". Are these
>> > functions not available for XDP program types?
>>
>> XDP programs cannot use bpf_l4_csum_replace, but they can use
>> bpf_csum_diff since commit 205c380 ("bpf: add csum_diff helper to xdp as
>> well") which landed in v4.16-rc1.
>
> I was thinking maybe those helpers were not available because no skb
> was construct. But after checking, the helper you're mentionning is in
> the tc_cls. Also, the csum_diff helper lies in the same switch
> statement as l4_csum_replace.
>
> Can you elaborate on why one can be used and not the other?

bpf_csum_diff only accesses packet data and can be used in both cls_act and xdp.
bpf_l4_csum_replace accesses skb data structure, e.g., it needs to
replace the csum
and hence needs to test whether skb is writable. It also different
calculation based on
the existing checksum state (skb->ip_summed), so bpf_l4_csum_replace cannot be
used in xdp.

>
> Thanks!
>
>
>





Re: Fixing stack trace function names by argument introspection

marko@kevac.org
 



On Mon, Jul 23, 2018 at 7:48 AM, Y Song <ys114321@...> wrote:

We did not have such an example in BCC. In Facebook, we have a bpf
program to catch
stack traces for python programs. It is very similar to what you want
to achieve in the above.

Can you share it with me? Maybe I can use it as an example.
 
Basically, you need to walk the stack by yourself. Since verifier do
not support unbounded loops,
you need to have a fully-unrollable loop with progma unroll.

I have never used pragma unroll before, but I understand what it is supposed to do.
Quick search gives me usages for CUDA and several little known examples for gcc/clang.

 
During each loop iteration, you can access the frame pointer, you need
some mechanism to
get the real function name based on that level frame pointer and then
you move on
to the next. In bpf program, you can access current task structure,
which contains some
data related to TLS which could be used by the bpf program.


As far as I understand it would work if my program is built with frame pointers. In that case going throigh stack trace shold be straightforward. Never done it before though :-)
But usually programs are build omitting frame pointers. In that case you need additional info from DWARF and code is much more complex. Right?
Are you suggesting implementing all this?

Sorry for newbie questions :-)


Re: Helper functions available for XDP?

Yonghong Song
 

On Tue, Jul 24, 2018 at 1:54 AM, François <fser@...> wrote:
On Mon, Jul 23, 2018 at 10:08:08PM +0200, Paul Chaignon wrote:
On Mon, Jul 23, 2018 at 02:21:05PM -0400, Andrew Wang wrote:
Hi

I am writing a bpf program for packet processing and have loaded my ingress
function at BPF.XDP.

I'm updating the destination IPv6 address and want to update the TCP
checksum, but when I try to call the helper functions "bpf_csum_diff" or
"bpf_l4_csum_replace", I get a "unknown func <function name>". Are these
functions not available for XDP program types?
XDP programs cannot use bpf_l4_csum_replace, but they can use
bpf_csum_diff since commit 205c380 ("bpf: add csum_diff helper to xdp as
well") which landed in v4.16-rc1.
I was thinking maybe those helpers were not available because no skb
was construct. But after checking, the helper you're mentionning is in
the tc_cls. Also, the csum_diff helper lies in the same switch
statement as l4_csum_replace.

Can you elaborate on why one can be used and not the other?
bpf_csum_diff only accesses packet data and can be used in both cls_act and xdp.
bpf_l4_csum_replace accesses skb data structure, e.g., it needs to
replace the csum
and hence needs to test whether skb is writable. It also different
calculation based on
the existing checksum state (skb->ip_summed), so bpf_l4_csum_replace cannot be
used in xdp.


Thanks!



Re: Helper functions available for XDP?

François
 

On Mon, Jul 23, 2018 at 10:08:08PM +0200, Paul Chaignon wrote:
On Mon, Jul 23, 2018 at 02:21:05PM -0400, Andrew Wang wrote:
Hi

I am writing a bpf program for packet processing and have loaded my ingress
function at BPF.XDP.

I'm updating the destination IPv6 address and want to update the TCP
checksum, but when I try to call the helper functions "bpf_csum_diff" or
"bpf_l4_csum_replace", I get a "unknown func <function name>". Are these
functions not available for XDP program types?
XDP programs cannot use bpf_l4_csum_replace, but they can use
bpf_csum_diff since commit 205c380 ("bpf: add csum_diff helper to xdp as
well") which landed in v4.16-rc1.
I was thinking maybe those helpers were not available because no skb
was construct. But after checking, the helper you're mentionning is in
the tc_cls. Also, the csum_diff helper lies in the same switch
statement as l4_csum_replace.

Can you elaborate on why one can be used and not the other?

Thanks!


Re: Helper functions available for XDP?

Paul Chaignon
 

On Mon, Jul 23, 2018 at 02:21:05PM -0400, Andrew Wang wrote:
Hi

I am writing a bpf program for packet processing and have loaded my ingress
function at BPF.XDP.

I'm updating the destination IPv6 address and want to update the TCP
checksum, but when I try to call the helper functions "bpf_csum_diff" or
"bpf_l4_csum_replace", I get a "unknown func <function name>". Are these
functions not available for XDP program types?
XDP programs cannot use bpf_l4_csum_replace, but they can use
bpf_csum_diff since commit 205c380 ("bpf: add csum_diff helper to xdp as
well") which landed in v4.16-rc1.


Is there a way to tell what helper functions are available to what program
types?
The list of helpers available to XDP programs is defined in function
xdp_func_proto in file net/core/filter.c of the Linux source code.
You might also want to check out pull request #1881 [1], which will
document helpers available to each program type in file kernel-versions.md
of bcc [2].

1 - https://github.com/iovisor/bcc/pull/1881
2 - https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md


Thanks
Andrew


Helper functions available for XDP?

Andrew Wang
 

Hi

I am writing a bpf program for packet processing and have loaded my ingress function at BPF.XDP. 

I'm updating the destination IPv6 address and want to update the TCP checksum, but when I try to call the helper functions "bpf_csum_diff" or "bpf_l4_csum_replace", I get a "unknown func <function name>". Are these functions not available for XDP program types? 

Is there a way to tell what helper functions are available to what program types?

Thanks
Andrew


Re: Fixing stack trace function names by argument introspection

Yonghong Song
 

On Sun, Jul 22, 2018 at 3:00 PM, marko@... <marko@...> wrote:
Hi!

Imagine I have an interpreter that runs some program in some custom
language. If I were to get a stack trace, it would look like:

sys_read() [k]
read()
execute_fn()
execute_fn()
execute_fn()
execute_fn()
main()

These execute_fn() functions execute functions defined in my custom
language. Such stack trace is not very helpful.

But I know that I can get to real function name through execute_fn()
arguments. Imagine it is as simple as execute_fn(char *real_fn_name).

I know I can trace execute_fn() invocations and get to this function name
through BCC/eBPF. But I would like to have tool similar to profile.py to be
able to profile my programs written in my custom language.

So I need to get stack traces periodically (49 Hz say) and I need to
substitute name of a function from execute_fn() to the real one from
arguments.

Can you give me some pointers how to do that or if it is possible at all.
I couldn't find any example that walks stack trace. All of the examples just
record them.
We did not have such an example in BCC. In Facebook, we have a bpf
program to catch
stack traces for python programs. It is very similar to what you want
to achieve in the above.
Basically, you need to walk the stack by yourself. Since verifier do
not support unbounded loops,
you need to have a fully-unrollable loop with progma unroll.

During each loop iteration, you can access the frame pointer, you need
some mechanism to
get the real function name based on that level frame pointer and then
you move on
to the next. In bpf program, you can access current task structure,
which contains some
data related to TLS which could be used by the bpf program.


Thanks!
Marko.


Fixing stack trace function names by argument introspection

marko@kevac.org
 

Hi!

Imagine I have an interpreter that runs some program in some custom language. If I were to get a stack trace, it would look like:

sys_read() [k]
read()
execute_fn()
execute_fn()
execute_fn()
execute_fn()
main()

These execute_fn() functions execute functions defined in my custom language. Such stack trace is not very helpful.

But I know that I can get to real function name through execute_fn() arguments. Imagine it is as simple as execute_fn(char *real_fn_name).

I know I can trace execute_fn() invocations and get to this function name through BCC/eBPF. But I would like to have tool similar to profile.py to be able to profile my programs written in my custom language.

So I need to get stack traces periodically (49 Hz say) and I need to substitute name of a function from execute_fn() to the real one from arguments.

Can you give me some pointers how to do that or if it is possible at all.
I couldn't find any example that walks stack trace. All of the examples just record them.

Thanks!
Marko.


Re: Accessing pinned eBPF map from the kernel

Yonghong Song
 

On Thu, Jul 19, 2018 at 2:49 PM, Hyunseok <hyunseok@...> wrote:
Thanks for your reply.

BPF_TABLE("extern") seems to work only if the eBPF program is loaded by the
same userspace process which creates the map, like in this example.
No. The example uses a locally-created map to illustrate the process,
but a pinned map
works in a similar way.

The user space application:
. using bpf_obj_get to get a FD for the pinned map.
. create TableDesc with the FD.
. Add TableDesc to the local_ts.
. Create a BPF object with the local_ts.
. ...

In the bpf program itself, declare the pinned map with "extern" type.


But, what if a map is created (and pinned) by process A, and an eBPF program
is loaded by another process B?
Is there any way for the eBPF program to access the pinned map?
Just follow the above process, it should work. Facebook has used the
same mechanism for a while to access externally-pinned maps.


bpf_obj_get cannot be used by eBPF programs as it is a userspace API.
bpf_obj_get() intends to be used in userspace, not kernel.



On Thu, Jul 19, 2018 at 3:33 PM, Y Song <ys114321@...> wrote:

The following is an example in C++ to import an external map to BPF
modules.
https://github.com/iovisor/bcc/blob/master/examples/cpp/UseExternalMap.cc
You can use libbpf function `bpf_obj_get` to get a map fd in the above
example.

On Wed, Jul 18, 2018 at 11:48 AM, <hyunseok@...> wrote:
Hi,

I have an eBPF map created and pinned by a userspace process.

Now I would like several eBPF programs to access this pinned eBPF map.

Is there any bcc APIs that can be used?

BPF_TABLE(), etc creates a new eBPF map, not loads an existing pinned
map.

Thanks,
-hs


Re: Accessing pinned eBPF map from the kernel

Hyunseok
 

Thanks for your reply.

BPF_TABLE("extern") seems to work only if the eBPF program is loaded by the same userspace process which creates the map, like in this example.

But, what if a map is created (and pinned) by process A, and an eBPF program is loaded by another process B?
Is there any way for the eBPF program to access the pinned map?

bpf_obj_get cannot be used by eBPF programs as it is a userspace API.


On Thu, Jul 19, 2018 at 3:33 PM, Y Song <ys114321@...> wrote:
The following is an example in C++ to import an external map to BPF modules.
https://github.com/iovisor/bcc/blob/master/examples/cpp/UseExternalMap.cc
You can use libbpf function `bpf_obj_get` to get a map fd in the above example.

On Wed, Jul 18, 2018 at 11:48 AM,  <hyunseok@...> wrote:
> Hi,
>
> I have an eBPF map created and pinned by a userspace process.
>
> Now I would like several eBPF programs to access this pinned eBPF map.
>
> Is there any bcc APIs that can be used?
>
> BPF_TABLE(), etc creates a new eBPF map, not loads an existing pinned map.
>
> Thanks,
> -hs


Re: problems with __sync_add_and_fetch in BPF code

Yonghong Song
 

On Wed, Jul 18, 2018 at 8:01 AM, Pablo Alvarez via Lists.Iovisor.Org
<palvarez=akamai.com@...> wrote:
Hi Daniel,

Yes. If you look at the bug report, you will see that what it actually
returns is some form of the increment. that is,

__sync_add_and_fetch(myptr, increment)

returns either increment or (increment * 2) (I am not sure which right now)

The fact that other builtins don't compile with LLVM is not too
surprising, given that it's a very restricted subset of C. The fact that
something does compile but then does not produce the promised result...
that's a little more of an issue!

Are there people on this list who have worked on the LLVM BPF compiler?
I might be willing to try to tackle fixing the bug, but I would need
some guidance...
Pablo,

I added the below comment in the bug report:

===

The table description for bpf_xadd operation is at BPFInstrInfo.td:

// Atomics
class XADD<BPFWidthModifer SizeOp, string OpcodeStr, PatFrag OpNode>
: TYPE_LD_ST<BPF_XADD.Value, SizeOp.Value,
(outs GPR:$dst),
(ins MEMri:$addr, GPR:$val),
"lock *("#OpcodeStr#" *)($addr) += $val",
[(set GPR:$dst, (OpNode ADDRri:$addr, GPR:$val))]> {
bits<4> dst;
bits<20> addr;

let Inst{51-48} = addr{19-16}; // base reg
let Inst{55-52} = dst;
let Inst{47-32} = addr{15-0}; // offset
let BPFClass = BPF_STX;
}

let Constraints = "$dst = $val" in {
def XADD32 : XADD<BPF_W, "u32", atomic_load_add_32>;
def XADD64 : XADD<BPF_DW, "u64", atomic_load_add_64>;
// undefined def XADD16 : XADD<1, "xadd16", atomic_load_add_16>;
// undefined def XADD8 : XADD<2, "xadd8", atomic_load_add_8>;
}
===

Please feel free to take a look how to address this issue.
I can help discussion/review along the way.

Thanks!

Yonghong



Best

Pablo Alvarez

On 07/18/18 09:27, Daniel Zozin wrote:
Hi Pablo,
I'm facing the same problem by compiling and running on kernel 4.15.
Calls to __sync_fetch_and_add keeps returning the same value while the
actual value has been incremented.
Also I add __sync_val_compare_and_swap to your list of primitives
generating compiling errors.

I Investigated a bit but I have no clue on how this can be fixed.

Daniel

On Wed, Jul 18, 2018 at 1:46 PM, Pablo Alvarez via Lists.Iovisor.Org
<https://urldefense.proofpoint.com/v2/url?u=http-3A__Lists.Iovisor.Org&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=0Y4-Ozye8rzL2OdOod5_xTXo5tWHsrs0CqSpjE-K1PQ&e=>
<palvarez=akamai.com@...
<mailto:palvarez=akamai.com@...>> wrote:

Hi all,

A while ago, I filed a bug with LLVM about __sync_add_and_fetch as
compiled into eBPF code.

https://bugs.llvm.org/show_bug.cgi?id=36573
<https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D36573&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=A4pMWnUIf29oD7glNQD3MEAAX27WhbV-L7TCaM9koNk&e=>

Both it and __sync_fetch_and_add fail to return the correct value of
the item being incremented, returning instead the increment (or
double the increment). This means I end up with race conditions. Has
anyone else run into this, and do you have a workaround for it?

The bug report, sadly, has not been touched by anyone else.

Best

Pablo Alvarez






--
Daniel Zozin, Dr.
Research Engineer
RiSING - Robust and Secure Distributed Computing
----------------------------------------
CREATE-NET Research Center
Fondazione Bruno Kessler (FBK)
via alla Cascata 56D
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstreetmap.org_search-3Fquery-3D46.07056-252C11.15092-23map-3D19_46.07056_11.15092-26layers-3DN&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=dk6ixv2SUmNaTT-TrXohRsrqnojkqI89jO8eHVMFhbM&e=>
38123 Povo, Trento (Italy)
Tel.: +39 0461 312480
e-mail: d.zozin@... <mailto:d.zozin@...>
www: https://create-net.fbk.eu/
<https://urldefense.proofpoint.com/v2/url?u=https-3A__create-2Dnet.fbk.eu_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=HU2BzKZl_Wb0rxi6vLbplXVWa-e4N2f1PD3e82TAk28&e=>
GPG KEY: 0x6F66193EC7034588

--
Le informazioni contenute nella presente comunicazione sono di
natura privata e come tali sono da considerarsi riservate ed
indirizzate esclusivamente ai destinatari indicati e per le finalità
strettamente legate al relativo contenuto. Se avete ricevuto questo
messaggio per errore, vi preghiamo di eliminarlo e di inviare una
comunicazione all’indirizzo e-mail del mittente.
--
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you received this in error, please contact the sender and
delete the material.


Re: Accessing pinned eBPF map from the kernel

Yonghong Song
 

The following is an example in C++ to import an external map to BPF modules.
https://github.com/iovisor/bcc/blob/master/examples/cpp/UseExternalMap.cc
You can use libbpf function `bpf_obj_get` to get a map fd in the above example.

On Wed, Jul 18, 2018 at 11:48 AM, <hyunseok@...> wrote:
Hi,

I have an eBPF map created and pinned by a userspace process.

Now I would like several eBPF programs to access this pinned eBPF map.

Is there any bcc APIs that can be used?

BPF_TABLE(), etc creates a new eBPF map, not loads an existing pinned map.

Thanks,
-hs


Re: Verifier error: variable stack access var_off

Yonghong Song
 

The kernel needs to a constant offset from the stack for write. The
corresponding kernel verifier code below:

/* stack accesses must be at a fixed offset, so that we can
* determine what type of data were returned.
* See check_stack_read().
*/
if (!tnum_is_const(reg->var_off)) {
char tn_buf[48];

tnum_strn(tn_buf, sizeof(tn_buf), reg->var_off);
verbose(env, "variable stack access var_off=%s
off=%d size=%d",
tn_buf, off, size);
return -EACCES;
}

You can initialize the array with ' ' to workaround the issue:
struct data_t data;
uint64_t max = sizeof(data.argv);
const char *argp = NULL;
memset(&data, ' ', sizeof(data));
bpf_probe_read(&argp, sizeof(argp), (void *)&__argv[0]);
uint64_t len = bpf_probe_read_str(&data.argv, max, argp);
len &= 0xffffffff; // to avoid: "math between fp pointer and register errs"
bpf_trace_printk("len: %d\\n", len); // sanity check: len is indeed valid

// data.argv[len] = ' ';

On Sun, Jul 1, 2018 at 6:20 PM, Teng Qin <palmtenor@...> wrote:
Firstly, note that bpf_probe_read_str adds an extra \0 to the read string.
So your max should be sizeof(data.argv) - 1 instead in order for
data.argv[len] = ' ' to work (from Verifier's perspective, logically you
don't need that extra delimiter~)

Then, Yonghong had a patch a few month ago addressing very similar issue.
See the example in patch series
bpf: improve verifier ARG_CONST_SIZE_OR_ZERO semantics
Does your Kernel have those patches?

However, even with all those the data.argv[len] = ' ' part still fails with
something about stack offset not being fixed. I will try debug more to see
how to fix that. For now, you can use a per-CPU array of size 1 for the data
instead of allocating it on the stack. The following works for me:
#include <uapi/linux/ptrace.h>
#include <linux/sched.h>
#include <linux/fs.h>

#define ARGSIZE 128

struct data_t {
char argv[ARGSIZE];
};

BPF_PERF_OUTPUT(events);
BPF_PERCPU_ARRAY(mem, struct data_t, 1);
//
// Here's what I'm trying to do. Let's say this has:
// __argv[0] = "ls"
// __argv[1] = "-l"
// I'm trying to create a buffer with "ls -l", by doing bpf_probe_read_str()
for
// each element into the buffer, while keeping track of the length of
// the previous read so I can insert a space delimiter at that offset,
// and begin the next read after the delimiter.
//
int on_event(struct pt_regs *ctx,
const char __user *filename,
const char __user *const __user *__argv,
const char __user *const __user *__envp)
{
int zero = 0;
struct data_t* data = mem.lookup(&zero);
if (!data)
return 0;

uint64_t max = sizeof(data->argv) - 1;
const char *argp = NULL;
bpf_probe_read(&argp, sizeof(argp), (void *)&__argv[0]);
uint64_t len = bpf_probe_read_str(&(data->argv), max, argp);
len &= 0xffffffff; // to avoid: "math between fp pointer and register
errs"
bpf_trace_printk("len: %d\\n", len); // sanity check: len is indeed
valid

data->argv[len] = ' ';

events.perf_submit(ctx, data, len);
out:
return 0;
}


Accessing pinned eBPF map from the kernel

Hyunseok
 

Hi,

I have an eBPF map created and pinned by a userspace process.

Now I would like several eBPF programs to access this pinned eBPF map.

Is there any bcc APIs that can be used?

BPF_TABLE(), etc creates a new eBPF map, not loads an existing pinned map.

Thanks,
-hs


Re: problems with __sync_add_and_fetch in BPF code

Alexei Starovoitov
 

On Wed, Jul 18, 2018 at 8:01 AM, Pablo Alvarez via Lists.Iovisor.Org
<palvarez=akamai.com@...> wrote:
Hi Daniel,

Yes. If you look at the bug report, you will see that what it actually
returns is some form of the increment. that is,

__sync_add_and_fetch(myptr, increment)
I added a comment to bugzilla.
Thank you for bringing it up.
It was considered a known quirk before, but we should improve it.
__sync_add_and_fetch semantics are cleaner and more useful
than what we have today.


Re: problems with __sync_add_and_fetch in BPF code

Pablo Alvarez
 

Hi Daniel,

Yes. If you look at the bug report, you will see that what it actually
returns is some form of the increment. that is,

__sync_add_and_fetch(myptr, increment)

returns either increment or (increment * 2) (I am not sure which right now)

The fact that other builtins don't compile with LLVM is not too
surprising, given that it's a very restricted subset of C. The fact that
something does compile but then does not produce the promised result...
that's a little more of an issue!

Are there people on this list who have worked on the LLVM BPF compiler?
I might be willing to try to tackle fixing the bug, but I would need
some guidance...

Best

Pablo Alvarez

On 07/18/18 09:27, Daniel Zozin wrote:
Hi Pablo,
I'm facing the same problem by compiling and running on kernel 4.15.
Calls to __sync_fetch_and_add keeps returning the same value while the
actual value has been incremented.
Also I add __sync_val_compare_and_swap to your list of primitives
generating compiling errors.

I Investigated a bit but I have no clue on how this can be fixed.

Daniel

On Wed, Jul 18, 2018 at 1:46 PM, Pablo Alvarez via Lists.Iovisor.Org
<https://urldefense.proofpoint.com/v2/url?u=http-3A__Lists.Iovisor.Org&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=0Y4-Ozye8rzL2OdOod5_xTXo5tWHsrs0CqSpjE-K1PQ&e=>
<palvarez=akamai.com@...
<mailto:palvarez=akamai.com@...>> wrote:

Hi all,

A while ago, I filed a bug with LLVM about __sync_add_and_fetch as
compiled into eBPF code.

https://bugs.llvm.org/show_bug.cgi?id=36573
<https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D36573&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=A4pMWnUIf29oD7glNQD3MEAAX27WhbV-L7TCaM9koNk&e=>

Both it and __sync_fetch_and_add fail to return the correct value of
the item being incremented, returning instead the increment (or
double the increment). This means I end up with race conditions. Has
anyone else run into this, and do you have a workaround for it?

The bug report, sadly, has not been touched by anyone else.

Best

Pablo Alvarez






--
Daniel Zozin, Dr.
Research Engineer
RiSING - Robust and Secure Distributed Computing
---------------------------------------- 
CREATE-NET Research Center
Fondazione Bruno Kessler (FBK)
via alla Cascata 56D
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstreetmap.org_search-3Fquery-3D46.07056-252C11.15092-23map-3D19_46.07056_11.15092-26layers-3DN&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=dk6ixv2SUmNaTT-TrXohRsrqnojkqI89jO8eHVMFhbM&e=>
38123 Povo, Trento (Italy)
Tel.: +39 0461 31​2480
e-mail: d.zozin@... <mailto:d.zozin@...>
www: https://create-net.fbk.eu/
<https://urldefense.proofpoint.com/v2/url?u=https-3A__create-2Dnet.fbk.eu_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=HU2BzKZl_Wb0rxi6vLbplXVWa-e4N2f1PD3e82TAk28&e=>
GPG KEY: 0x6F66193EC7034588

--
Le informazioni contenute nella presente comunicazione sono di
natura privata e come tali sono da considerarsi riservate ed
indirizzate esclusivamente ai destinatari indicati e per le finalità
strettamente legate al relativo contenuto. Se avete ricevuto questo
messaggio per errore, vi preghiamo di eliminarlo e di inviare una
comunicazione all’indirizzo e-mail del mittente.
--
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you received this in error, please contact the sender and
delete the material.

621 - 640 of 2021