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: > > On Tue, 3 Mar 2020 20:36:45 -0800 Alexei Starovoitov wrote: > > > > > 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. > > > 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.. > > > 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. > > > > 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. > > > > > > > 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? > > > > > > > > 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. > > Surely all of this can > > be done from user space. > > with a camera for theft monitoring. that will work well. > > > 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.
