Date   

Re: how to starts ? but It is fully installed :)

Dorian ROSSE
 

I have only a nework bandwitch (if It is writtin as previous) of 700 / 800 kilobites secondes I think It is called a little network

Regards.


Dorian ROSSE.

 

Provenance : Courrier pour Windows 10

 


De : Jugurtha BELKALEM <jugurtha.belkalem@...>
Envoyé : Tuesday, May 14, 2019 12:22:40 PM
À : Dorian ROSSE
Cc : iovisor-dev@...
Objet : Re: [iovisor-dev] how to starts ? but It is fully installed :)
 
Yes, it can work for your network, however you should tune the number of received packets(MAX_NB_PACKETS) as well as the interval between two successive packets depending on your network (LEGAL_DIFF_TIMESTAMP_PACKETS).

But if you are in a network with low traffic, you can keep the default settings in the script and do the test as described here : https://github.com/iovisor/bcc/blob/master/examples/tracing/dddos_example.txt.

Regards.


Re: how to starts ? but It is fully installed :)

Jugurtha BELKALEM
 

Yes, it can work for your network, however you should tune the number of received packets(MAX_NB_PACKETS) as well as the interval between two successive packets depending on your network (LEGAL_DIFF_TIMESTAMP_PACKETS).

But if you are in a network with low traffic, you can keep the default settings in the script and do the test as described here : https://github.com/iovisor/bcc/blob/master/examples/tracing/dddos_example.txt.

Regards.


Re: how to starts ? but It is fully installed :)

Dorian ROSSE
 

I have a question for you Jugurtha please :

Do the DDOS Detector can works all the time for my networks 😊   ?

Thank you in advance to answer by yes or no,

Regards.


Dorian ROSSE.

 


De : Jugurtha BELKALEM <jugurtha.belkalem@...>
Envoyé : Tuesday, May 14, 2019 12:08:35 PM
À : Dorian ROSSE
Cc : iovisor-dev@...
Objet : Re: [iovisor-dev] how to starts ? but It is fully installed :)
 
Hi Dorian,

I have already written an article in french for bcc : http://www.linuxembedded.fr/2019/03/les-secrets-du-traceur-ebpf/.

Have a good reading.

Regards.


Re: how to starts ? but It is fully installed :)

Dorian ROSSE
 

Tank you Jugurtha 😊

 

Provenance : Courrier pour Windows 10

 


De : Jugurtha BELKALEM <jugurtha.belkalem@...>
Envoyé : Tuesday, May 14, 2019 12:08:35 PM
À : Dorian ROSSE
Cc : iovisor-dev@...
Objet : Re: [iovisor-dev] how to starts ? but It is fully installed :)
 
Hi Dorian,

I have already written an article in french for bcc : http://www.linuxembedded.fr/2019/03/les-secrets-du-traceur-ebpf/.

Have a good reading.

Regards.


Re: how to starts ? but It is fully installed :)

Jugurtha BELKALEM
 

Hi Dorian,

I have already written an article in french for bcc : http://www.linuxembedded.fr/2019/03/les-secrets-du-traceur-ebpf/.

Have a good reading.

Regards.


how to starts ? but It is fully installed :)

Dorian ROSSE
 

Hello everybody,


I have installed the bcc programs but Do you know bcc tutorial in french because my English is as a buddy lol

Thank you in advance to bring your help 😊

Have a nice Week,

Regards.


Azaretdodo.

 

 

Provenance : Courrier pour Windows 10

 


eBPF program to replicate packets

Prashanth Fernando
 

 

Hi,

 

Will it be possible to replicate packets using XDP. e,g, capture pkt on if-a look for any match and then replicate the packets, modify the IP address send it out of if-a.

 

 

Best Regards,

Prashanth

 

 


minutes: IO Visor TSC/Dev Meeting

Brenden Blanco
 

Hi All,

Thanks for joining in to the call this week. As usual, here are my notes.

Cheers,
Brenden

=== Discussion ===
Yonghong:
* Code reviews mostly
* bpfd (client/server approach) effort paused
* seeing if compile-once/run-everywhere can replace this effort
* signal helper (from bpf prog to process)
* hhvm accepts a signal, dumps stack, easier than collecting from bpf side

Jiong:
* Tuning 32 bit patch set
* Power PC users did some testing and reported bugs in unit test
* v5 expected soon

Matheus:
* Features and test improvements
* Support for array index access
* 'cat' feature
* USDT

Jesper:
* Tried to play with BTF, but libbpf failed to load with some kernel configs
* There are some known issues, Yonghong says that it will get some attention
and hopefully improve soon.

=== Attendees ===
Brenden Blanco
Matheus Marchini
Dan Siemon
Richard Elling
Jesper Brouer
Yonghong Song
Jiong Wang
Quentin Monnet


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=2019&month=5&day=1&hour=18&min=0&sec=0&p1=900


Re: bpftrace and include search paths?

Richard Elling
 



On Apr 23, 2019, at 12:36 PM, Matheus Marchini <mat@...> wrote:

We use the clang library to process includes, so any environment
variable that clang accepts should work. I haven't tested it, but
CPATH is listed in clang's documentation, so it should work as well.
C_INCLUDE_PATH will force the includes to only be used if clang is
parsing a .c file (which it always is in bpftrace context).

Thanks Matheus, CPATH works for sure, C_INCLUDE_PATH I'll need to verify. 
I'll send a docs PR when I get a chance.
 -- richard




On Fri, Apr 12, 2019 at 1:55 PM Richard Elling
<richard.elling@...> wrote:



On Apr 4, 2019, at 1:38 PM, Brendan Gregg <brendan.d.gregg@...> wrote:

C_INCLUDE_PATH=... environment variable should work.


Yes, thanks. Though CPATH seems to be more universal. I'll work up some docs and
submit a PR.

Now, if I can find an equivalent to dtrace's print(arg[0])...
-- richard



But you can file an RFE or PR anyway to add this to the docs. Thanks!

Brendan

On Thu, Apr 4, 2019 at 12:41 PM Richard Elling <richard.elling@...> wrote:

I have a need to have a bpftrace script #include headers from a project
directory. In cc, this is like adding -I<path>. Am I blind from reading manuals
or is there a clever way to pass that info down through bpftrace into bpf or
is this a new RFE?
-- richard






Re: bpftrace and include search paths?

Matheus Marchini <mat@...>
 

We use the clang library to process includes, so any environment
variable that clang accepts should work. I haven't tested it, but
CPATH is listed in clang's documentation, so it should work as well.
C_INCLUDE_PATH will force the includes to only be used if clang is
parsing a .c file (which it always is in bpftrace context).


On Fri, Apr 12, 2019 at 1:55 PM Richard Elling
<richard.elling@...> wrote:



On Apr 4, 2019, at 1:38 PM, Brendan Gregg <brendan.d.gregg@...> wrote:

C_INCLUDE_PATH=... environment variable should work.


Yes, thanks. Though CPATH seems to be more universal. I'll work up some docs and
submit a PR.

Now, if I can find an equivalent to dtrace's print(arg[0])...
-- richard



But you can file an RFE or PR anyway to add this to the docs. Thanks!

Brendan

On Thu, Apr 4, 2019 at 12:41 PM Richard Elling <richard.elling@...> wrote:

I have a need to have a bpftrace script #include headers from a project
directory. In cc, this is like adding -I<path>. Am I blind from reading manuals
or is there a clever way to pass that info down through bpftrace into bpf or
is this a new RFE?
-- richard




minutes: IO Visor TSC/Dev Meeting

Brenden Blanco
 

Hi All,

Thanks for joining the call today. As usual, here are my notes.

Thanks,
Brenden

=== Discussion ===

Yonghong:
- compile once run everywhere work continues
- some prototypes for internal projects
- some details to be presented at BPF microconference later this month
- implement helper to send signals to other processes in the system
- some bcc work on bpfd, patches to be reviewed
- (bpfd is a remote bcc tool for low resource systems)

Matheus:
- macro support in bpftrace
- porting to new version of llvm pass manager
- old version has some memory issues
- bpftrace issue #528
- request for jenkins support
- Ubuntu 18.04 (4.15 or later)
- ai for Brenden

Daniel:
- bpf global data support got merged
- cilium - masquerade support native in bpf

John:
- bounded loop work has resumed in llvm, hopefully something to review in a
couple weeks
- some sockmap and ktls fixes

Martin:
- Socket local storage work
- userspace looks like a regular map
- a new helper to be implemented
- local storage will be in the socket
- memory charged to option memory of the socket

Brendan:
- Writing some advanced networking tools in bpftrace

Dan:
question about AF_XDP:
- is the intention that user mem can be large?
- 5-10k subscribers with ~10 packets each
- may require some work to support hugepages
- some of the docs on the tx use case are somewhat lacking

=== Attendees ===
Brenden Blanco
Augusto Caringi
John Fastabend
Flavio Crisciani
Michael Savisko
Matheus
Dan Siemon
Marco Leogrande
Yonghong Song
Jakub Kicisnki
Paul Chaignon
Joe Stringer
Daniel Borkmann
Brendan Gregg
Martin Lau
Quentin Monnet
Saeed


Re: [PATCHv5 RFC 1/3] BPF: New helper to obtain namespace data from current task (FIX).

neirac
 

I'm sorry there was an error on the code, the spinlock was never released if kern_path()
failed.Here is the fix.

diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index 2de82d14424d..2a83eba63182 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -359,11 +359,11 @@ BPF_CALL_2(bpf_get_current_pidns_info, struct bpf_pidns_info *, pidns_info, u32,

spin_lock(&bpf_spinlock);
ret = kern_path(pidnspath, 0, &kp);
+ spin_unlock(&bpf_spinlock);
if (ret)
goto clear;
inode = d_backing_inode(kp.dentry);
pidns_info->dev = inode->i_sb->s_dev;
- spin_unlock(&bpf_spinlock);

return 0;

On Tue, Apr 16, 2019 at 09:31:35PM -0400, cnb via Lists.Iovisor.Org wrote:
As a bpf program cannot sleep, I needed to add a spinlock to kern_path, as
it calls getname_kernel() which may sleep.
The inode is accessed directly, as we are just interested in the inode's s_dev.
Let me know if this approach is the correct one.
-------------------------------------------------------------------------------
From 35b7bfcbf6524ec807f107302209a0fb07614cc8 Mon Sep 17 00:00:00 2001
From: Carlos <cneirabustos@...>
Date: Tue, 16 Apr 2019 17:10:46 -0400
Subject: [PATCH] [PATCH bpf-next 1/3] BPF: New helper to obtain namespace data
from current task

This helper obtains the active namespace from current and returns pid, tgid,
device and namespace id as seen from that namespace, allowing to instrument
a process inside a container.
Device is read from /proc/self/ns/pid, as in the future it's possible that
different pid_ns files may belong to different devices, according
to the discussion between Eric Biederman and Yonghong in 2017 linux plumbers
conference.
Currently bpf_get_current_pid_tgid(), is used to do pid filtering in bcc's
scripts but this helper returns the pid as seen by the root namespace which is
fine when a bcc script is not executed inside a container.
When the process of interest is inside a container, pid filtering will not work
if bpf_get_current_pid_tgid() is used. This helper addresses this limitation
returning the pid as it's seen by the current namespace where the script is
executing.

This helper has the same use cases as bpf_get_current_pid_tgid() as it can be
used to do pid filtering even inside a container.

For example a bcc script using bpf_get_current_pid_tgid() (tools/funccount.py):

u32 pid = bpf_get_current_pid_tgid() >> 32;
if (pid != <pid_arg_passed_in>)
return 0;
Could be modified to use bpf_get_current_pidns_info() as follows:

struct bpf_pidns pidns;
bpf_get_current_pidns_info(&pidns, sizeof(struct bpf_pidns));
u32 pid = pidns.tgid;
u32 nsid = pidns.nsid;
if ((pid != <pid_arg_passed_in>) && (nsid != <nsid_arg_passed_in>))
return 0;

To find out the name PID namespace id of a process, you could use this command:

$ ps -h -o pidns -p <pid_of_interest>

Or this other command:

$ ls -Li /proc/<pid_of_interest>/ns/pid

Signed-off-by: Carlos Antonio Neira Bustos <cneirabustos@...>
---
include/linux/bpf.h | 1 +
include/uapi/linux/bpf.h | 25 ++++++++++++++++++-
kernel/bpf/core.c | 1 +
kernel/bpf/helpers.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++
kernel/trace/bpf_trace.c | 2 ++
5 files changed, 93 insertions(+), 1 deletion(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index e4d4c1771ab0..4393f8f088cc 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -987,6 +987,7 @@ extern const struct bpf_func_proto bpf_sk_redirect_map_proto;
extern const struct bpf_func_proto bpf_spin_lock_proto;
extern const struct bpf_func_proto bpf_spin_unlock_proto;
extern const struct bpf_func_proto bpf_get_local_storage_proto;
+extern const struct bpf_func_proto bpf_get_current_pidns_info_proto;

/* Shared helpers among cBPF and eBPF. */
void bpf_user_rnd_init_once(void);
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 31a27dd337dc..7bf457875c31 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -2500,6 +2500,18 @@ union bpf_attr {
* Return
* 0 if iph and th are a valid SYN cookie ACK, or a negative error
* otherwise.
+ *
+ * int bpf_get_current_pidns_info(struct bpf_pidns_info *pidns, u32 size_of_pidns)
+ * Description
+ * Copies into *pidns* pid, namespace id and tgid as seen by the
+ * current namespace and also device from /proc/self/ns/pid.
+ * *size_of_pidns* must be the size of *pidns*
+ *
+ * This helper is used when pid filtering is needed inside a
+ * container as bpf_get_current_tgid() helper returns always the
+ * pid id as seen by the root namespace.
+ * Return
+ * 0 on success -EINVAL on error.
*/
#define __BPF_FUNC_MAPPER(FN) \
FN(unspec), \
@@ -2602,7 +2614,8 @@ union bpf_attr {
FN(skb_ecn_set_ce), \
FN(get_listener_sock), \
FN(skc_lookup_tcp), \
- FN(tcp_check_syncookie),
+ FN(tcp_check_syncookie), \
+ FN(get_current_pidns_info),

/* integer value in 'imm' field of BPF_CALL instruction selects which helper
* function eBPF program intends to call
@@ -3298,4 +3311,14 @@ struct bpf_line_info {
struct bpf_spin_lock {
__u32 val;
};
+
+/* helper bpf_get_current_pidns_info will store the following
+ * data, dev will contain major/minor from /proc/self/pid.
+*/
+struct bpf_pidns_info {
+ __u32 dev;
+ __u32 nsid;
+ __u32 tgid;
+ __u32 pid;
+};
#endif /* _UAPI__LINUX_BPF_H__ */
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index ace8c22c8b0e..ecbdc72ba459 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -2046,6 +2046,7 @@ const struct bpf_func_proto bpf_get_current_uid_gid_proto __weak;
const struct bpf_func_proto bpf_get_current_comm_proto __weak;
const struct bpf_func_proto bpf_get_current_cgroup_id_proto __weak;
const struct bpf_func_proto bpf_get_local_storage_proto __weak;
+const struct bpf_func_proto bpf_get_current_pidns_info __weak;

const struct bpf_func_proto * __weak bpf_get_trace_printk_proto(void)
{
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index a411fc17d265..2de82d14424d 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -18,6 +18,11 @@
#include <linux/sched.h>
#include <linux/uidgid.h>
#include <linux/filter.h>
+#include <linux/pid_namespace.h>
+#include <linux/major.h>
+#include <linux/stat.h>
+#include <linux/namei.h>
+#include <linux/version.h>

/* If kernel subsystem is allowing eBPF programs to call this function,
* inside its own verifier_ops->get_func_proto() callback it should return
@@ -317,6 +322,66 @@ void copy_map_value_locked(struct bpf_map *map, void *dst, void *src,
preempt_enable();
}

+BPF_CALL_2(bpf_get_current_pidns_info, struct bpf_pidns_info *, pidns_info, u32,
+ size)
+{
+ const char *pidnspath = "/proc/self/ns/pid";
+ struct pid_namespace *pidns = NULL;
+ DEFINE_SPINLOCK(bpf_spinlock);
+ struct inode *inode;
+ struct kstat ks;
+ struct path kp;
+ pid_t tgid = 0;
+ pid_t pid = 0;
+ int ret;
+
+ if (unlikely(size != sizeof(struct bpf_pidns_info)))
+ goto clear;
+
+ pidns = task_active_pid_ns(current);
+
+ if (unlikely(!pidns))
+ goto clear;
+
+ pidns_info->nsid = pidns->ns.inum;
+ pid = task_pid_nr_ns(current, pidns);
+
+ if (unlikely(!pid))
+ goto clear;
+
+ tgid = task_tgid_nr_ns(current, pidns);
+
+ if (unlikely(!tgid))
+ goto clear;
+
+ pidns_info->tgid = (u32) tgid;
+ pidns_info->pid = (u32) pid;
+
+ spin_lock(&bpf_spinlock);
+ ret = kern_path(pidnspath, 0, &kp);
+ if (ret)
+ goto clear;
+ inode = d_backing_inode(kp.dentry);
+ pidns_info->dev = inode->i_sb->s_dev;
+ spin_unlock(&bpf_spinlock);
+
+ return 0;
+
+ clear:
+ if (pidns_info)
+ memset((void *)pidns, 0, (size_t) size);
+
+ return -EINVAL;
+}
+
+const struct bpf_func_proto bpf_get_current_pidns_info_proto = {
+ .func = bpf_get_current_pidns_info,
+ .gpl_only = false,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_PTR_TO_UNINIT_MEM,
+ .arg2_type = ARG_CONST_SIZE,
+};
+
#ifdef CONFIG_CGROUPS
BPF_CALL_0(bpf_get_current_cgroup_id)
{
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index d64c00afceb5..2ef0de78d4ec 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -603,6 +603,8 @@ tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
case BPF_FUNC_get_current_cgroup_id:
return &bpf_get_current_cgroup_id_proto;
#endif
+ case BPF_FUNC_get_current_pidns_info:
+ return &bpf_get_current_pidns_info_proto;
default:
return NULL;
}
--
2.11.0




[PATCHv5 RFC 1/3] BPF: New helper to obtain namespace data from current task.

neirac
 

As a bpf program cannot sleep, I needed to add a spinlock to kern_path, as
it calls getname_kernel() which may sleep.
The inode is accessed directly, as we are just interested in the inode's s_dev.
Let me know if this approach is the correct one.
-------------------------------------------------------------------------------
From 35b7bfcbf6524ec807f107302209a0fb07614cc8 Mon Sep 17 00:00:00 2001
From: Carlos <cneirabustos@...>
Date: Tue, 16 Apr 2019 17:10:46 -0400
Subject: [PATCH] [PATCH bpf-next 1/3] BPF: New helper to obtain namespace data
from current task

This helper obtains the active namespace from current and returns pid, tgid,
device and namespace id as seen from that namespace, allowing to instrument
a process inside a container.
Device is read from /proc/self/ns/pid, as in the future it's possible that
different pid_ns files may belong to different devices, according
to the discussion between Eric Biederman and Yonghong in 2017 linux plumbers
conference.
Currently bpf_get_current_pid_tgid(), is used to do pid filtering in bcc's
scripts but this helper returns the pid as seen by the root namespace which is
fine when a bcc script is not executed inside a container.
When the process of interest is inside a container, pid filtering will not work
if bpf_get_current_pid_tgid() is used. This helper addresses this limitation
returning the pid as it's seen by the current namespace where the script is
executing.

This helper has the same use cases as bpf_get_current_pid_tgid() as it can be
used to do pid filtering even inside a container.

For example a bcc script using bpf_get_current_pid_tgid() (tools/funccount.py):

u32 pid = bpf_get_current_pid_tgid() >> 32;
if (pid != <pid_arg_passed_in>)
return 0;
Could be modified to use bpf_get_current_pidns_info() as follows:

struct bpf_pidns pidns;
bpf_get_current_pidns_info(&pidns, sizeof(struct bpf_pidns));
u32 pid = pidns.tgid;
u32 nsid = pidns.nsid;
if ((pid != <pid_arg_passed_in>) && (nsid != <nsid_arg_passed_in>))
return 0;

To find out the name PID namespace id of a process, you could use this command:

$ ps -h -o pidns -p <pid_of_interest>

Or this other command:

$ ls -Li /proc/<pid_of_interest>/ns/pid

Signed-off-by: Carlos Antonio Neira Bustos <cneirabustos@...>
---
include/linux/bpf.h | 1 +
include/uapi/linux/bpf.h | 25 ++++++++++++++++++-
kernel/bpf/core.c | 1 +
kernel/bpf/helpers.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++
kernel/trace/bpf_trace.c | 2 ++
5 files changed, 93 insertions(+), 1 deletion(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index e4d4c1771ab0..4393f8f088cc 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -987,6 +987,7 @@ extern const struct bpf_func_proto bpf_sk_redirect_map_proto;
extern const struct bpf_func_proto bpf_spin_lock_proto;
extern const struct bpf_func_proto bpf_spin_unlock_proto;
extern const struct bpf_func_proto bpf_get_local_storage_proto;
+extern const struct bpf_func_proto bpf_get_current_pidns_info_proto;

/* Shared helpers among cBPF and eBPF. */
void bpf_user_rnd_init_once(void);
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 31a27dd337dc..7bf457875c31 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -2500,6 +2500,18 @@ union bpf_attr {
* Return
* 0 if iph and th are a valid SYN cookie ACK, or a negative error
* otherwise.
+ *
+ * int bpf_get_current_pidns_info(struct bpf_pidns_info *pidns, u32 size_of_pidns)
+ * Description
+ * Copies into *pidns* pid, namespace id and tgid as seen by the
+ * current namespace and also device from /proc/self/ns/pid.
+ * *size_of_pidns* must be the size of *pidns*
+ *
+ * This helper is used when pid filtering is needed inside a
+ * container as bpf_get_current_tgid() helper returns always the
+ * pid id as seen by the root namespace.
+ * Return
+ * 0 on success -EINVAL on error.
*/
#define __BPF_FUNC_MAPPER(FN) \
FN(unspec), \
@@ -2602,7 +2614,8 @@ union bpf_attr {
FN(skb_ecn_set_ce), \
FN(get_listener_sock), \
FN(skc_lookup_tcp), \
- FN(tcp_check_syncookie),
+ FN(tcp_check_syncookie), \
+ FN(get_current_pidns_info),

/* integer value in 'imm' field of BPF_CALL instruction selects which helper
* function eBPF program intends to call
@@ -3298,4 +3311,14 @@ struct bpf_line_info {
struct bpf_spin_lock {
__u32 val;
};
+
+/* helper bpf_get_current_pidns_info will store the following
+ * data, dev will contain major/minor from /proc/self/pid.
+*/
+struct bpf_pidns_info {
+ __u32 dev;
+ __u32 nsid;
+ __u32 tgid;
+ __u32 pid;
+};
#endif /* _UAPI__LINUX_BPF_H__ */
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index ace8c22c8b0e..ecbdc72ba459 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -2046,6 +2046,7 @@ const struct bpf_func_proto bpf_get_current_uid_gid_proto __weak;
const struct bpf_func_proto bpf_get_current_comm_proto __weak;
const struct bpf_func_proto bpf_get_current_cgroup_id_proto __weak;
const struct bpf_func_proto bpf_get_local_storage_proto __weak;
+const struct bpf_func_proto bpf_get_current_pidns_info __weak;

const struct bpf_func_proto * __weak bpf_get_trace_printk_proto(void)
{
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index a411fc17d265..2de82d14424d 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -18,6 +18,11 @@
#include <linux/sched.h>
#include <linux/uidgid.h>
#include <linux/filter.h>
+#include <linux/pid_namespace.h>
+#include <linux/major.h>
+#include <linux/stat.h>
+#include <linux/namei.h>
+#include <linux/version.h>

/* If kernel subsystem is allowing eBPF programs to call this function,
* inside its own verifier_ops->get_func_proto() callback it should return
@@ -317,6 +322,66 @@ void copy_map_value_locked(struct bpf_map *map, void *dst, void *src,
preempt_enable();
}

+BPF_CALL_2(bpf_get_current_pidns_info, struct bpf_pidns_info *, pidns_info, u32,
+ size)
+{
+ const char *pidnspath = "/proc/self/ns/pid";
+ struct pid_namespace *pidns = NULL;
+ DEFINE_SPINLOCK(bpf_spinlock);
+ struct inode *inode;
+ struct kstat ks;
+ struct path kp;
+ pid_t tgid = 0;
+ pid_t pid = 0;
+ int ret;
+
+ if (unlikely(size != sizeof(struct bpf_pidns_info)))
+ goto clear;
+
+ pidns = task_active_pid_ns(current);
+
+ if (unlikely(!pidns))
+ goto clear;
+
+ pidns_info->nsid = pidns->ns.inum;
+ pid = task_pid_nr_ns(current, pidns);
+
+ if (unlikely(!pid))
+ goto clear;
+
+ tgid = task_tgid_nr_ns(current, pidns);
+
+ if (unlikely(!tgid))
+ goto clear;
+
+ pidns_info->tgid = (u32) tgid;
+ pidns_info->pid = (u32) pid;
+
+ spin_lock(&bpf_spinlock);
+ ret = kern_path(pidnspath, 0, &kp);
+ if (ret)
+ goto clear;
+ inode = d_backing_inode(kp.dentry);
+ pidns_info->dev = inode->i_sb->s_dev;
+ spin_unlock(&bpf_spinlock);
+
+ return 0;
+
+ clear:
+ if (pidns_info)
+ memset((void *)pidns, 0, (size_t) size);
+
+ return -EINVAL;
+}
+
+const struct bpf_func_proto bpf_get_current_pidns_info_proto = {
+ .func = bpf_get_current_pidns_info,
+ .gpl_only = false,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_PTR_TO_UNINIT_MEM,
+ .arg2_type = ARG_CONST_SIZE,
+};
+
#ifdef CONFIG_CGROUPS
BPF_CALL_0(bpf_get_current_cgroup_id)
{
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index d64c00afceb5..2ef0de78d4ec 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -603,6 +603,8 @@ tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
case BPF_FUNC_get_current_cgroup_id:
return &bpf_get_current_cgroup_id_proto;
#endif
+ case BPF_FUNC_get_current_pidns_info:
+ return &bpf_get_current_pidns_info_proto;
default:
return NULL;
}
--
2.11.0


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=2019&month=4&day=17&hour=18&min=0&sec=0&p1=900


Re: bpftrace and include search paths?

Richard Elling
 



On Apr 4, 2019, at 1:38 PM, Brendan Gregg <brendan.d.gregg@...> wrote:

C_INCLUDE_PATH=... environment variable should work.

Yes, thanks. Though CPATH seems to be more universal. I'll work up some docs and
submit a PR.

Now, if I can find an equivalent to dtrace's print(arg[0])...
 -- richard



But you can file an RFE or PR anyway to add this to the docs. Thanks!

Brendan

On Thu, Apr 4, 2019 at 12:41 PM Richard Elling <richard.elling@...> wrote:
I have a need to have a bpftrace script #include headers from a project
directory. In cc, this is like adding -I<path>. Am I blind from reading manuals
or is there a clever way to pass that info down through bpftrace into bpf or
is this a new RFE?
 -- richard






Re: R? min value is negative, either use unsigned or 'var &= const' #verifier

Yonghong Song
 

On Thu, Apr 11, 2019 at 8:37 AM Simon <contact@...> wrote:

I finally discover that checksum can be calculated via incremental update. (see RFC 1624)

Using it, I didn't have to deal with dynamic sized payload and so no more issue with the verifier.
Glad you find a solution!


So I go back to use bcc :)

Again, Thx a lot Yonghong for your time !

Please don't forget to keep me in touch about that even if I'm not impacted anymore, I'm curious to know how you move forward on this !
Sure.


(By the way did you get the point about the error just above, is the verifier able to understand this kind of dynamic check ?)
Verifier understands some dynamic check if these dynamic check is
resolved to be constant vs. variable or constant vs. constant compares
during path sensitive verification.



Re: R? min value is negative, either use unsigned or 'var &= const' #verifier

Simon
 

I finally discover that checksum can be calculated via incremental update. (see RFC 1624)

Using it, I didn't have to deal with dynamic sized payload and so no more issue with the verifier.

So I go back to use bcc :)

Again, Thx a lot Yonghong for your time !

Please don't forget to keep me in touch about that even if I'm not impacted anymore, I'm curious to know how you move forward on this !

(By the way did you get the point about the error just above, is the verifier able to understand this kind of dynamic check ?)


Re: minutes: IO Visor TSC/Dev Meeting

Jiong Wang
 

Great, will have a look, thanks!

Regards,
Jiong
On 05/04/2019 07:45, Y Song wrote:

Hi, Jiong,

To follow up the iovisor meeting discussion, the below is my prototype
for an end_loop
instruction in llvm:
https://github.com/yonghong-song/llvm/commit/b83226772100317092cae6478229ed6ca3b9903c
The goal is to help verifier to just focus on these marked cases,
rejecting any other backedges.

Please let me and John know if you get some better idea for bounded
loop support in llvm/verifier.

Thanks,

Yonghong

On Wed, Apr 3, 2019 at 11:49 AM Brenden Blanco <bblanco@...> wrote:
Hi All,

Thanks for the good discussion today! Below are my notes.

Thanks,
Brenden

=== Discussion ===
[...]
Yonghong:
* Compile once run anywhere work continues
  * bitfield handling bugs in IR/debuginfo

Daniel:
* Global support work continues
  * BTF side patches submitted to bpf mailing list
  * tests included

Jiong:
* 32 bit patch set
  * test methodology improvements
  * updated patches later in the week
  * some concerns around shifts, to be addressed in later improvements

Andrii:
* BTF and compile-once work integration
  to share prototype tool with Saeed

Brendan:
* Is there a tool to measure queue latency in qdisc->netdev layer?
  * debian/ubuntu are packaging bpftrace
  * except libbcc renamed to libbpf_cc
  * some issues with mixing iovisor's libbcc and debian's

Jesper:
* Fedora adding packaging support for libbpf

Alexei:
* systemd also adding support for libbpf - link to be provided?

=== Attendees ===
Brenden Blanco
Andril Nakryiko
Daniel Borkmann
Jesper Brouer
Jiong Wang
Marco Leogrande
Michael Savisko
Paul Chaignon
Quentin Monnet
Alexei Starovoitov
Saeed
Flavio
Rony
Jonathan Lemon
Brendan Gregg
Dan Siemon
Joe Stringer
John




Re: minutes: IO Visor TSC/Dev Meeting

Yonghong Song
 

Hi, Jiong,

To follow up the iovisor meeting discussion, the below is my prototype
for an end_loop
instruction in llvm:
https://github.com/yonghong-song/llvm/commit/b83226772100317092cae6478229ed6ca3b9903c
The goal is to help verifier to just focus on these marked cases,
rejecting any other backedges.

Please let me and John know if you get some better idea for bounded
loop support in llvm/verifier.

Thanks,

Yonghong

On Wed, Apr 3, 2019 at 11:49 AM Brenden Blanco <bblanco@...> wrote:

Hi All,

Thanks for the good discussion today! Below are my notes.

Thanks,
Brenden

=== Discussion ===
[...]
Yonghong:
* Compile once run anywhere work continues
* bitfield handling bugs in IR/debuginfo

Daniel:
* Global support work continues
* BTF side patches submitted to bpf mailing list
* tests included

Jiong:
* 32 bit patch set
* test methodology improvements
* updated patches later in the week
* some concerns around shifts, to be addressed in later improvements

Andrii:
* BTF and compile-once work integration
to share prototype tool with Saeed

Brendan:
* Is there a tool to measure queue latency in qdisc->netdev layer?
* debian/ubuntu are packaging bpftrace
* except libbcc renamed to libbpf_cc
* some issues with mixing iovisor's libbcc and debian's

Jesper:
* Fedora adding packaging support for libbpf

Alexei:
* systemd also adding support for libbpf - link to be provided?

=== Attendees ===
Brenden Blanco
Andril Nakryiko
Daniel Borkmann
Jesper Brouer
Jiong Wang
Marco Leogrande
Michael Savisko
Paul Chaignon
Quentin Monnet
Alexei Starovoitov
Saeed
Flavio
Rony
Jonathan Lemon
Brendan Gregg
Dan Siemon
Joe Stringer
John


361 - 380 of 2021