netdev - Re: [RFC 1/2] netvsc: invoke xdp_generic from VF frame handler

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 15 May 2019 16:12:42 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Stephen Hemminger <stephen@...workplumber.org>, kys@...rosoft.com,
        haiyangz@...rosoft.com, davem@...emloft.net
Cc:     netdev@...r.kernel.org, Stephen Hemminger <sthemmin@...rosoft.com>
Subject: Re: [RFC 1/2] netvsc: invoke xdp_generic from VF frame handler


On 2019/5/15 下午4:03, Stephen Hemminger wrote:
> XDP generic does not work correctly with the Hyper-V/Azure netvsc
> device because of packet processing order. Only packets on the
> synthetic path get seen by the XDP program. The VF device packets
> are not seen.
>
> By the time the packets that arrive on the VF are handled by
> netvsc after the first pass of XDP generic (on the VF) has already
> been done.
>
> A fix for the netvsc device is to do this in the VF packet handler.
> by directly calling do_xdp_generic() if XDP program is present
> on the parent device.
>
> A riskier but maybe better alternative would be to do this netdev core
> code after the receive handler is invoked (if RX_HANDLER_ANOTHER
> is returned).


Something like what I propose at 
https://lore.kernel.org/patchwork/patch/973819/ ?

It belongs to a series that try to make XDP (both native and generic) 
work for stacked device. But for some reason (probably performance), the 
maintainer seems not like the idea.

Maybe it's time to reconsider that?

Thanks


>
> Fixes: 0c195567a8f6 ("netvsc: transparent VF management")
> Signed-off-by: Stephen Hemminger <sthemmin@...rosoft.com>
> ---
>   drivers/net/hyperv/netvsc_drv.c | 6 ++++++
>   1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 06393b215102..bb0fc1869bde 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -1999,9 +1999,15 @@ static rx_handler_result_t netvsc_vf_handle_frame(struct sk_buff **pskb)
>   	struct net_device_context *ndev_ctx = netdev_priv(ndev);
>   	struct netvsc_vf_pcpu_stats *pcpu_stats
>   		 = this_cpu_ptr(ndev_ctx->vf_stats);
> +	struct bpf_prog *xdp_prog;
>   
>   	skb->dev = ndev;
>   
> +	xdp_prog = rcu_dereference(ndev->xdp_prog);
> +	if (xdp_prog &&
> +	    do_xdp_generic(xdp_prog, skb) != XDP_PASS)
> +		return RX_HANDLER_CONSUMED;
> +
>   	u64_stats_update_begin(&pcpu_stats->syncp);
>   	pcpu_stats->rx_packets++;
>   	pcpu_stats->rx_bytes += skb->len;