From: Stanislav Fomichev <sdf@google.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
martin.lau@linux.dev, razor@blackwall.org, ast@kernel.org,
andrii@kernel.org, john.fastabend@gmail.com, toke@kernel.org,
kuba@kernel.org, andrew@lunn.ch
Subject: Re: [PATCH bpf-next v3 1/7] netkit, bpf: Add bpf programmable net device
Date: Tue, 24 Oct 2023 11:27:15 -0700 [thread overview]
Message-ID: <ZTgMg3HfFohvISSF@google.com> (raw)
In-Reply-To: <ca1f0aaa-94c2-5e7d-1d00-a640bb3be44a@iogearbox.net>
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
👍
next prev parent reply other threads:[~2023-10-24 18:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-23 17:18 [PATCH bpf-next v3 0/7] Add bpf programmable net device Daniel Borkmann
2023-10-23 17:18 ` [PATCH bpf-next v3 1/7] netkit, bpf: " Daniel Borkmann
2023-10-24 16:07 ` Toke Høiland-Jørgensen
2023-10-24 18:16 ` Daniel Borkmann
2023-10-24 16:40 ` Stanislav Fomichev
2023-10-24 18:05 ` Daniel Borkmann
2023-10-24 18:27 ` Stanislav Fomichev [this message]
2023-10-24 19:58 ` Daniel Borkmann
2023-10-23 17:18 ` [PATCH bpf-next v3 2/7] tools: Sync if_link uapi header Daniel Borkmann
2023-10-23 17:18 ` [PATCH bpf-next v3 3/7] libbpf: Add link-based API for netkit Daniel Borkmann
2023-10-23 17:18 ` [PATCH bpf-next v3 4/7] bpftool: Implement link show support " Daniel Borkmann
2023-10-24 16:08 ` Toke Høiland-Jørgensen
2023-10-23 17:18 ` [PATCH bpf-next v3 5/7] bpftool: Extend net dump with netkit progs Daniel Borkmann
2023-10-23 17:18 ` [PATCH bpf-next v3 6/7] selftests/bpf: Add netlink helper library Daniel Borkmann
2023-10-23 17:18 ` [PATCH bpf-next v3 7/7] selftests/bpf: Add selftests for netkit Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZTgMg3HfFohvISSF@google.com \
--to=sdf@google.com \
--cc=andrew@lunn.ch \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=razor@blackwall.org \
--cc=toke@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).