netdev - RE: [PATCH net 5/5] qede: Split PF/VF ndos.

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 17 May 2017 06:16:46 +0000
From:   "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net 5/5] qede: Split PF/VF ndos.

> PFs and VFs share the same structure of NDOs today, and the VFs explicitly
> fails the ndo_xdp() callback stating it doesn't support XDP.
> 
> This results in lots of:
> 
>   [qede_xdp:1032(enp131s2)]VFs don't support XDP
>   ------------[ cut here ]------------
>   WARNING: CPU: 4 PID: 1426 at net/core/rtnetlink.c:1637
> rtnl_dump_ifinfo+0x354/0x3c0
>   ...
>   Call Trace:
>     ? __alloc_skb+0x9b/0x1d0
>     netlink_dump+0x122/0x290
>     netlink_recvmsg+0x27d/0x430
>     sock_recvmsg+0x3d/0x50
>   ...
> 
> As every dump request for the VF interface info would fail due to
> rtnl_xdp_fill() returning an error code.
> 
> To resolve this, introduce a subset of the NDOs meant for the VF in a
> seperate structure and register that one instead for VFs, and omit the
> ndo_xdp initialization.
> 
> Fixes: 40b8c45492ef ("qede: Prevent VFs from using XDP")
> Signed-off-by: Yuval Mintz <Yuval.Mintz@...ium.com>

I'm currently working on adding XDP support for qede VFs.
Problem is there's quite a bit of IOV infrastructure involved in this,
and legacy [well, current] PFs would prevent their VFs from utilizing it.

Once I have it ready, if I'd add back the ndo_xdp unconditionally for VFs,
then when working over legacy PFs above issue would resurface.

Looking at my alternatives for solving this, I can't see any 'good' options -
it seems mightily unorthodox to modify net_device_ops, I.e., add/remove
an NDO function-pointer based on some device property, and having
multiple ops declared for the sake of a single feature seems unscalable.

Any better solutions?