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: Sun, 24 Jul 2016 22:34:38 +0200 From: Daniel Borkmann <daniel@...earbox.net> To: Tom Herbert <tom@...bertland.com>, Brenden Blanco <bblanco@...mgrid.com> CC: "David S. Miller" <davem@...emloft.net>, Linux Kernel Network Developers <netdev@...r.kernel.org>, Jamal Hadi Salim <jhs@...atatu.com>, Saeed Mahameed <saeedm@....mellanox.co.il>, Martin KaFai Lau <kafai@...com>, Jesper Dangaard Brouer <brouer@...hat.com>, Ari Saha <as754m@....com>, Alexei Starovoitov <alexei.starovoitov@...il.com>, Or Gerlitz <gerlitz.or@...il.com>, john fastabend <john.fastabend@...il.com>, Hannes Frederic Sowa <hannes@...essinduktion.org>, Thomas Graf <tgraf@...g.ch>, Tariq Toukan <ttoukan.linux@...il.com> Subject: Re: [PATCH v10 05/12] net/mlx4_en: add support for fast rx drop bpf program On 07/24/2016 06:57 PM, Tom Herbert wrote: > On Tue, Jul 19, 2016 at 2:16 PM, Brenden Blanco <bblanco@...mgrid.com> wrote: >> Add support for the BPF_PROG_TYPE_XDP hook in mlx4 driver. >> >> In tc/socket bpf programs, helpers linearize skb fragments as needed >> when the program touches the packet data. However, in the pursuit of >> speed, XDP programs will not be allowed to use these slower functions, >> especially if it involves allocating an skb. >> >> Therefore, disallow MTU settings that would produce a multi-fragment >> packet that XDP programs would fail to access. Future enhancements could >> be done to increase the allowable MTU. >> >> The xdp program is present as a per-ring data structure, but as of yet >> it is not possible to set at that granularity through any ndo. >> >> Signed-off-by: Brenden Blanco <bblanco@...mgrid.com> [...] >> + if (prog) { >> + prog = bpf_prog_add(prog, priv->rx_ring_num - 1); >> + if (IS_ERR(prog)) >> + return PTR_ERR(prog); >> + } >> + >> + priv->xdp_ring_num = xdp_ring_num; >> + >> + /* This xchg is paired with READ_ONCE in the fast path */ >> + for (i = 0; i < priv->rx_ring_num; i++) { >> + old_prog = xchg(&priv->rx_ring[i]->xdp_prog, prog); > > This can be done under a lock instead of relying on xchg. > >> + if (old_prog) >> + bpf_prog_put(old_prog); > > I don't see how this can work. Even after setting the new program, the > old program might still be run (pointer dereferenced before xchg). > Either rcu needs to be used or the queue should stopped and synced > before setting the new program. It's a strict requirement that all BPF programs must run under RCU.
Powered by blists - more mailing lists