On Tue, 20 Aug 2024 00:01:02 -0400 Mina Almasry wrote: > Took a bit of a look here. Forgive me, I'm not that familiar with XDP > and virtual interfaces, so I'm a bit unsure what to do here. > > For veth, it seems, the device behind the veth is stored in > veth_priv->peer, so it seems maybe a dev_get_max_mp_channel() check on > veth_priv->peer is the way to go to disable this for veth? I think we > need to do this check on creation of the veth and on the ndo_bpf of > veth. veth is a SW device pair, it can't reasonably support netmem. Given all the unreasonable features it grew over time we can't rule out that someone will try, but that's not our problem now. > For bonding, it seems we need to add mp channel check in bond_xdp_set, > and bond_enslave? Sort of, I'd factor out that logic into the core first, as some sort of "xdp propagate" helper. Then we can add that check once. I don't see anything bond specific in the logic. > There are a few other drivers that define ndo_add_slave, seems a check > in br_add_slave is needed as well. I don't think it's that broad. Not many drivers propagate XDP: $ git grep -C 200 '\.ndo_add_slave' | grep '\.ndo_bpf' drivers/net/bonding/bond_main.c- .ndo_bpf = bond_xdp, $ git grep --files-with-matches 'ops->ndo_bpf' -- drivers/ drivers/net/bonding/bond_main.c drivers/net/hyperv/netvsc_bpf.c > This seems like a potentially deep rabbit hole with a few checks to > add all of the place. Is this blocking the series? Protecting the stack from unreadable memory is *the* challenge in this series. The rest is a fairly straightforward.
