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: Fri, 8 Apr 2016 10:04:25 -0700 From: Brenden Blanco <bblanco@...mgrid.com> To: Jesper Dangaard Brouer <brouer@...hat.com> Cc: davem@...emloft.net, netdev@...r.kernel.org, tom@...bertland.com, alexei.starovoitov@...il.com, ogerlitz@...lanox.com, daniel@...earbox.net, eric.dumazet@...il.com, ecree@...arflare.com, john.fastabend@...il.com, tgraf@...g.ch, johannes@...solutions.net, eranlinuxmellanox@...il.com, lorenzo@...gle.com Subject: Re: [RFC PATCH v2 4/5] mlx4: add support for fast rx drop bpf program On Fri, Apr 08, 2016 at 01:41:58PM +0200, Jesper Dangaard Brouer wrote: > > On Thu, 7 Apr 2016 21:48:49 -0700 Brenden Blanco <bblanco@...mgrid.com> wrote: > > > +int mlx4_call_bpf(struct bpf_prog *prog, void *data, unsigned int length) > > +{ > > + struct sk_buff *skb = this_cpu_ptr(&percpu_bpf_phys_dev_md); > > + int ret; > > + > > + build_bpf_phys_dev_md(skb, data, length); > > + > > + rcu_read_lock(); > > + ret = BPF_PROG_RUN(prog, (void *)skb); > > + rcu_read_unlock(); > > + > > + return ret; > > +} > [...] > > > diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c > > index 86bcfe5..287da02 100644 > > --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c > > +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c > > @@ -840,6 +843,23 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud > > l2_tunnel = (dev->hw_enc_features & NETIF_F_RXCSUM) && > > (cqe->vlan_my_qpn & cpu_to_be32(MLX4_CQE_L2_TUNNEL)); > > > > + /* A bpf program gets first chance to drop the packet. It may > > + * read bytes but not past the end of the frag. > > + */ > > + if (prog) { > > + struct ethhdr *ethh; > > + dma_addr_t dma; > > + > > + dma = be64_to_cpu(rx_desc->data[0].addr); > > + dma_sync_single_for_cpu(priv->ddev, dma, sizeof(*ethh), > > + DMA_FROM_DEVICE); > > + ethh = page_address(frags[0].page) + > > + frags[0].page_offset; > > + if (mlx4_call_bpf(prog, ethh, frags[0].page_size) == > > + BPF_PHYS_DEV_DROP) > > + goto next; > > + } > > + > > Do the program need to know if the packet-page we handover is > considered 'read-only' at the call site? Or do we rely on my idea > requiring the registration to "know" this... Seems that we're leaning towards the latter at this point. In either case, we won't allow buggy situations, and let's see which approach works better when we have RFC code in hand. > > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Principal Kernel Engineer at Red Hat > Author of http://www.iptv-analyzer.org > LinkedIn: http://www.linkedin.com/in/brouer
Powered by blists - more mailing lists