From: Stanislav Fomichev <sdf@google.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Martin KaFai Lau <martin.lau@linux.dev>,
ast@kernel.org, andrii@kernel.org, song@kernel.org, yhs@fb.com,
john.fastabend@gmail.com, kpsingh@kernel.org, haoluo@google.com,
jolsa@kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 2/2] bpf: bring back removal of dev-bound id from idr
Date: Wed, 22 Nov 2023 10:05:35 -0800 [thread overview]
Message-ID: <ZV5C7099HylvusQO@google.com> (raw)
In-Reply-To: <b4854a4b-a692-8164-5684-4315939966f3@iogearbox.net>
On 11/22, Daniel Borkmann wrote:
> On 11/21/23 10:03 PM, Martin KaFai Lau wrote:
> > On 11/13/23 8:54 PM, Stanislav Fomichev wrote:
> > > Commit ef01f4e25c17 ("bpf: restore the ebpf program ID for BPF_AUDIT_UNLOAD
> > > and PERF_BPF_EVENT_PROG_UNLOAD") stopped removing program's id from
> > > idr when the offloaded/bound netdev goes away. I was supposed to
> > > take a look and check in [0], but apparently I did not.
> > >
> > > The purpose of idr removal is to avoid BPF_PROG_GET_NEXT_ID returning
> > > stale ids for the programs that have a dead netdev. This functionality
> >
> > What may be wrong if BPF_PROG_GET_NEXT_ID returns the id?
> > e.g. If the prog is pinned somewhere, it may be useful to know a prog is still loaded in the system.
bpftool is a bit spooked by those prog ids currently: calling GET_INFO_BY_ID
on those programs returns ENODEV. So we can keep those ids around, but
need some tweaks on the bpftool in this case. LMK if any of you prefer
this option.
> Wouldn't this strictly speaking provide an invalid id (== 0) upon unload
> back to audit - see the bpf_audit_prog(prog, BPF_AUDIT_UNLOAD) call location?
Removing from idr shouldn't affect bpf_audit_prog, right? bpf_audit_prog
is using prog->aux->id for its purposes, so as long as we are not resetting
this value - we're good.
next prev parent reply other threads:[~2023-11-22 18:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 4:54 [PATCH bpf-next 0/2] bpf: fix couple of netdevsim issues Stanislav Fomichev
2023-11-14 4:54 ` [PATCH bpf-next 1/2] netdevsim: don't accept device bound programs Stanislav Fomichev
2023-11-20 21:38 ` Stanislav Fomichev
2023-11-20 21:58 ` Jakub Kicinski
2023-11-14 4:54 ` [PATCH bpf-next 2/2] bpf: bring back removal of dev-bound id from idr Stanislav Fomichev
2023-11-20 21:39 ` Stanislav Fomichev
2023-11-21 21:03 ` Martin KaFai Lau
2023-11-22 15:07 ` Daniel Borkmann
2023-11-22 18:05 ` Stanislav Fomichev [this message]
2023-11-22 18:40 ` Martin KaFai Lau
2023-11-22 22:41 ` Stanislav Fomichev
2023-11-22 22:54 ` 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=ZV5C7099HylvusQO@google.com \
--to=sdf@google.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=song@kernel.org \
--cc=yhs@fb.com \
/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