lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <y0m1tt226lj.fsf@fche.csb> Date: Wed, 30 Jul 2014 11:45:28 -0400 From: fche@...hat.com (Frank Ch. Eigler) To: Alexei Starovoitov <ast@...mgrid.com> Cc: "David S. Miller" <davem@...emloft.net>, Ingo Molnar <mingo@...nel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Andy Lutomirski <luto@...capital.net>, Steven Rostedt <rostedt@...dmis.org>, Daniel Borkmann <dborkman@...hat.com>, Chema Gonzalez <chema@...gle.com>, Eric Dumazet <edumazet@...gle.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Arnaldo Carvalho de Melo <acme@...radead.org>, Jiri Olsa <jolsa@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, "H. Peter Anvin" <hpa@...or.com>, Andrew Morton <akpm@...ux-foundation.org>, Kees Cook <keescook@...omium.org>, linux-api@...r.kernel.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH RFC v3 net-next 3/3] samples: bpf: eBPF dropmon example in C ast wrote earlier: > [...] > dtrace/systemtap/ktap approach is to use one script file that should provide > all desired functionality. That architectural decision overcomplicated their > implementations. > > eBPF follows split model: everything that needs to process millions of events > per second needs to run in kernel and needs to be short and deterministic, > all other things like aggregation and nice graphs should run in user space. > [...] For the record, this is not entirely accurate as to dtrace. dtrace delegates aggregation and most reporting to userspace. Also, systemtap is "short and deterministic" even for aggregations & nice graphs, but since it limits its storage & cpu consumption, its arrays/reports cannot get super large. > [...] > +SEC("events/skb/kfree_skb") > +int bpf_prog2(struct bpf_context *ctx) > +{ > +[...] > + value = bpf_map_lookup_elem(&my_map, &loc); > + if (value) > + (*(long *) value) += 1; > + else > + bpf_map_update_elem(&my_map, &loc, &init_val); > + return 0; > +} What kind of locking/serialization is provided by the ebpf runtime over shared variables such as my_map? - FChE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists