From: Martin KaFai Lau <martin.lau@linux.dev>
To: Stanislav Fomichev <sdf@google.com>,
Daniel Borkmann <daniel@iogearbox.net>
Cc: 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:40:47 -0800 [thread overview]
Message-ID: <20c42052-8cb7-4b8b-a7f8-d9311e37479d@linux.dev> (raw)
In-Reply-To: <ZV5C7099HylvusQO@google.com>
On 11/22/23 10:05 AM, 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.
I think it is in general useful to improve 'bpftool prog show' to keep going for
the next prog id if possible. May be print an error message after the prog id
and then keep going for the next prog id?
next prev parent reply other threads:[~2023-11-22 18:40 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
2023-11-22 18:40 ` Martin KaFai Lau [this message]
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=20c42052-8cb7-4b8b-a7f8-d9311e37479d@linux.dev \
--to=martin.lau@linux.dev \
--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=sdf@google.com \
--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