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? > > 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. > 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.
