On Wed, 4 Mar 2020 12:45:07 -0800 Alexei Starovoitov wrote:

On Wed, Mar 04, 2020 at 11:41:58AM -0800, Jakub Kicinski wrote:

quoted

On Tue, 3 Mar 2020 20:36:45 -0800 Alexei Starovoitov wrote:  

quoted

quoted

quoted

libxdp can choose to pin it in some libxdp specific location, so other
libxdp-enabled applications can find it in the same location, detach,
replace, modify, but random app that wants to hack an xdp prog won't
be able to mess with it.    

What if that "random app" comes first, and keeps holding on to the link
fd? Then the admin essentially has to start killing processes until they
find the one that has the device locked, no?    

Of course not. We have to provide an api to make it easy to discover
what process holds that link and where it's pinned.  

That API to discover ownership would be useful but it's on the BPF side.  

it's on bpf side because it's bpf specific.

quoted

We have netlink notifications in networking world. The application
which doesn't want its program replaced should simply listen to the
netlink notifications and act if something goes wrong.  

instead of locking the bike let's setup a camera and monitor the bike
when somebody steals it.
and then what? chase the thief and bring the bike back?

:) Is the bike the BPF program? It's more like thief is stealing our
parking spot, we still have the program :)

Maybe also the thief should not have CAP_ADMIN in the first place?
And ask a daemon to perform its actions..

quoted

quoted

But if we go with notifier approach none of it is an issue.  

Sorry, what's the notifier approach? You mean netdev notifier chain 
or something new?  

that's tbd.

quoted

quoted

Whether target obj is held or notifier is used everything I said before still
stands. "random app" that uses netlink after libdispatcher got its link FD will
not be able to mess with carefully orchestrated setup done by libdispatcher.

Also either approach will guarantee that infamous message:
"unregister_netdevice: waiting for %s to become free. Usage count"
users will never see.
 

quoted

And what about the case where the link fd is pinned on a bpffs that is
no longer available? I.e., if a netdevice with an XDP program moves
namespaces and no longer has access to the original bpffs, that XDP
program would essentially become immutable?    

'immutable' will not be possible.
I'm not clear to me how bpffs is going to disappear. What do you mean
exactly?
  

quoted

quoted

We didn't come up with these design choices overnight. It came from
hard lessons learned while deploying xdp, tc and cgroup in production.
Legacy apis will not be deprecated, of course.    

This sounds like a version of devm_* helpers for configuration.
Why are current user space APIs insufficient?   

current xdp, tc, cgroup apis don't have the concept of the link
and owner of that link.

Why do the attachment points have to have a concept of an owner and 
not the program itself?

Link is a very overloaded term, I may not comprehend very well that 
it models because of that.

quoted

Surely all of this can 
be done from user space.  

with a camera for theft monitoring. that will work well.

quoted

And we will need a centralized daemon for XDP
dispatch, so why is it not a part of a daemon?  

current design of libdispatcher doesn't need the deamon.

Which is flawed. Why do we want to solve a distributed problem 
of multiple applications with potentially a different version 
of a library cooperating. When we can make it a daemon.