On Tue, Aug 20, 2024 at 11:19 AM Jakub Kicinski kuba@kernel.org wrote:
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
OK, got it, I'll take a deeper look and hopefully figure out something reasonable here.
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.
Understandable. I pulled the trigger on v21 with the build fix last night after reading your response on the other thread. If you manage to review that and let me know of any other issues I'm going to run into down the road, that would be great. But I read in some other thread that you're overloaded. Sorry if I'm piling on. Feel free to cr it if necessary, of course.
-- Thanks, Mina