On 09/28, Jakub Kicinski wrote: > An upper device installs its XDP program on each lower with > dev_xdp_propagate(), which calls ndo_bpf() directly and records nothing > in the lower's xdp_state[]. netif_xdp_propagate() open-codes two of the > checks dev_xdp_install() makes, but the lower still looks program-free > to everything else, so the checks made in the opposite direction miss it > entirely: > > ethtool -G $slave tcp-data-split on > > is refused by dev_xdp_sb_prog_count() for a device running a > single-buffer XDP program, but not for a bond slave running the bond's, > even though netif_xdp_propagate() would have refused to install that > same program had header-data split been on already. Binding a memory > provider has the same asymmetry. The lower does not report the program > over rtnetlink either, so it is invisible to userspace as well. > > Install it into xdp_state[] like any other program and mark it with > xdp_from_upper, rather than tracking it separately. Every existing user > of dev_xdp_prog_count() and dev_xdp_sb_prog_count() then gets the right > answer with no changes. The flag is only needed where the owner matters: > bonding reads it to tell a slave's own program apart from the one it > pushed down, both to refuse enslaving such a device and to let the > bond-wide program be replaced, and dev_xdp_attach() reads it to keep the > program from being replaced or removed behind the upper's back. > > The lower now holds its own reference, as it does for a program of its > own; the upper's per-lower reference for the driver is unchanged. > > While here, refuse to propagate onto a device which has a program of its > own, matching dev_xdp_install(). Bonding checks this before enslaving > and before installing, netvsc does not and would silently replace the > VF's program. > > Signed-off-by: Jakub Kicinski <[email protected]>
Acked-by: Stanislav Fomichev <[email protected]>
