Re: [PATCH bpf-next v3 1/7] netkit, bpf: Add bpf programmable net device

[Stanislav Fomichev <sdf@google.com>]

On 10/24, Daniel Borkmann wrote:
> On 10/24/23 6:40 PM, Stanislav Fomichev wrote:
> > On 10/23, Daniel Borkmann wrote:
> [...]
> > The series looks great! FWIW:
> > Acked-by: Stanislav Fomichev <sdf@google.com>
> 
> Thanks for review!
> 
> > One small question I have is:
> > We now (and after introduction of tcx) seem to store non-refcounted
> > dev pointers in the bpf_link(s). Is it guaranteed that the dev will
> > outlive the link?
> 
> The semantics are the same as it was done in XDP, meaning, the link is in
> detached state so link->dev is NULL when dev goes away, see also the
> dev_xdp_uninstall(). We cannot hold a refcount on the dev as otherwise
> if the link outlives it we get the infamous "unregister_netdev...waiting
> for <dev>... refcnt = 1" bug.

Yeah, I remember I've had a similar issue with holding netdev when
adding dev-bound programs, so I was wondering what are we doing here.
Thanks for the pointers! 

And here, I guess the assumption that the device shutdown goes via
dellink (netkit_del_link) and there is no special path that reaches
unregister_netdevice_many_notify otherwise, right?

What about that ndo_uninit btw? Would it be more safe/clear to make
netkit_release_all be ndo_uninit? Looks like it's being triggered
in a place similar to dev_xdp_uninstall/dev_tcx_uninstall.

> > > +	ret = netkit_link_prog_attach(&nkl->link,
> > > +				      attr->link_create.flags,
> > > +				      attr->link_create.netkit.relative_fd,
> > > +				      attr->link_create.netkit.expected_revision);
> > > +	if (ret) {
> > > +		nkl->dev = NULL;
> > > +		bpf_link_cleanup(&link_primer);
> > > +		goto out;
> > 
> > What happens to nkl here? Do we leak it?
> 
> No, this is done similarly as in XDP and tcx, that is, bpf_link_cleanup() will
> trigger eventual release of nlk here :
> 
> /* Clean up bpf_link and corresponding anon_inode file and FD. After
>  * anon_inode is created, bpf_link can't be just kfree()'d due to deferred
>  * anon_inode's release() call. This helper marks bpf_link as
>  * defunct, releases anon_inode file and puts reserved FD. bpf_prog's refcnt
>  * is not decremented, it's the responsibility of a calling code that failed
>  * to complete bpf_link initialization.
>  * This helper eventually calls link's dealloc callback, but does not call
>  * link's release callback.
>  */
> 
> Thanks,
> Daniel

👍