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
| ||
|
Date: Wed, 12 Mar 2014 15:43:02 -0700 From: Alexei Starovoitov <ast@...mgrid.com> To: Cong Wang <cwang@...pensource.com> Cc: "David S. Miller" <davem@...emloft.net>, Daniel Borkmann <dborkman@...hat.com>, Ingo Molnar <mingo@...nel.org>, Will Drewry <wad@...omium.org>, Steven Rostedt <rostedt@...dmis.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, "H. Peter Anvin" <hpa@...or.com>, Hagen Paul Pfeifer <hagen@...u.net>, Jesse Gross <jesse@...ira.com>, Thomas Gleixner <tglx@...utronix.de>, Eric Dumazet <edumazet@...gle.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...ux-foundation.org>, Frederic Weisbecker <fweisbec@...il.com>, Arnaldo Carvalho de Melo <acme@...radead.org>, Pekka Enberg <penberg@....fi>, Arjan van de Ven <arjan@...radead.org>, Christoph Hellwig <hch@...radead.org>, Pavel Emelyanov <xemul@...allels.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, netdev <netdev@...r.kernel.org> Subject: Re: [PATCH v9 net-next 1/3] filter: add Extended BPF interpreter and converter On Wed, Mar 12, 2014 at 3:16 PM, Cong Wang <cwang@...pensource.com> wrote: > (Sorry for jumping into this thread late.) > > On Mon, Mar 10, 2014 at 9:41 PM, Alexei Starovoitov <ast@...mgrid.com> wrote: >> >> 3. tracing filters systemtap-like with extended BPF >> >> 4. OVS with extended BPF >> >> 5. nftables with extended BPF > > If you plan to use extended BPF out of networking, does > it make sense to make it independent of networking? > That is, rename those sk_*() APIs? well, v1 and v2 series already demonstrate how ebpf can be used for tracing. That's why in v1 series they were under kernel/ dir, but since it's a natural bpf extension that reuses a lot of bpf pieces, it makes sense for the whole thing be in net/core/filter.c and in linux/filter.h I believe that was a consensus in v2-v3 series. I don't want to rename the whole thing once again. Also seccomp is not networking, but it already uses bpf and after these patches ebpf. So net/core/filter.c location is fine. >> >> +int bpf_ext_enable __read_mostly; >> + > > This could be converted to a jump label, no? yes, but it's not in critical path, so no need. Thank you for taking a look! Even late feedback is always appreciated. -- 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