On Tue, Aug 20, 2024 at 11:19 AM Jakub Kicinski [off-list ref] wrote:

On Tue, 20 Aug 2024 00:01:02 -0400 Mina Almasry wrote:

quoted

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.

quoted

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.

quoted

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.

quoted

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