BPF List
 help / color / mirror / Atom feed
From: Quentin Monnet <qmo@kernel.org>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	YiFei Zhu <zhuyifei@google.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Kenta Tada <tadakentaso@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Ian Rogers <irogers@google.com>, Greg Thelen <gthelen@google.com>,
	Mahesh Bandewar <maheshb@google.com>,
	Minh-Anh Nguyen <minhanhdn@google.com>,
	Sagarika Sharma <sharmasagarika@google.com>,
	XuanYao Zhang <xuanyao@google.com>
Subject: Re: [PATCH bpf] bpftool: Fix regression of "bpftool cgroup tree" EINVAL on older kernels
Date: Thu, 1 May 2025 21:04:34 +0100	[thread overview]
Message-ID: <55e5aab0-6aa7-4b79-908a-5cbfdc7bd7cd@kernel.org> (raw)
In-Reply-To: <CAEf4BzZXpWC8nWb4zF37PpDX0Y+Bk9=vw8iL5Ehqcjr-Bw=dNQ@mail.gmail.com>

2025-05-01 10:54 UTC-0700 ~ Andrii Nakryiko <andrii.nakryiko@gmail.com>
> On Mon, Apr 28, 2025 at 2:15 PM YiFei Zhu <zhuyifei@google.com> wrote:
>>
>> If cgroup_has_attached_progs queries an attach type not supported
>> by the running kernel, due to the kernel being older than the bpftool
>> build, it would encounter an -EINVAL from BPF_PROG_QUERY syscall.
>>
>> Prior to commit 98b303c9bf05 ("bpftool: Query only cgroup-related
>> attach types"), this EINVAL would be ignored by the function, allowing
>> the function to only consider supported attach types. The commit
>> changed so that, instead of querying all attach types, only attach
>> types from the array `cgroup_attach_types` is queried. The assumption
>> is that because these are only cgroup attach types, they should all
>> be supported. Unfortunately this assumption may be false when the
>> kernel is older than the bpftool build, where the attach types queried
>> by bpftool is not yet implemented in the kernel. This would result in
>> errors such as:
>>
>>   $ bpftool cgroup tree
>>   CgroupPath
>>   ID       AttachType      AttachFlags     Name
>>   Error: can't query bpf programs attached to /sys/fs/cgroup: Invalid argument
>>
>> This patch restores the logic of ignoring EINVAL from prior to that patch.
>>
>> Fixes: 98b303c9bf05 ("bpftool: Query only cgroup-related attach types")
>> Reported-by: Sagarika Sharma <sharmasagarika@google.com>
>> Reported-by: Minh-Anh Nguyen <minhanhdn@google.com>
>> Signed-off-by: YiFei Zhu <zhuyifei@google.com>
>> ---
>>  tools/bpf/bpftool/cgroup.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
>> index 93b139bfb9880..3f1d6be512151 100644
>> --- a/tools/bpf/bpftool/cgroup.c
>> +++ b/tools/bpf/bpftool/cgroup.c
>> @@ -221,7 +221,7 @@ static int cgroup_has_attached_progs(int cgroup_fd)
>>         for (i = 0; i < ARRAY_SIZE(cgroup_attach_types); i++) {
>>                 int count = count_attached_bpf_progs(cgroup_fd, cgroup_attach_types[i]);
>>
>> -               if (count < 0)
>> +               if (count < 0 && errno != EINVAL)
>>                         return -1;
> 
> let's maybe change count_attached_bpf_progs() to return error directly
> as returned by bpf_prog_query(), instead of translating that to -1 and
> then requiring relying on errno?
> 
> so just
> 
> if (ret)
>     return ret;
> 
> and then just
> 
> if (count < 0 && count != -EINVAL)
>     return /* well whatever, I'd return error probably instead of -1 again */
> 
> Thoughts?

It feels maybe slightly less intuitive to me to compare "count" - rather
than "errno" - with "-EINVAL", but I don't mind really. It does make
sense to check the return code from the function. Looks OK from my side.

Thanks,
Quentin

  reply	other threads:[~2025-05-01 20:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-28 21:15 [PATCH bpf] bpftool: Fix regression of "bpftool cgroup tree" EINVAL on older kernels YiFei Zhu
2025-04-29  9:09 ` Quentin Monnet
2025-05-01 17:54 ` Andrii Nakryiko
2025-05-01 20:04   ` Quentin Monnet [this message]
2025-05-01 22:30     ` YiFei Zhu
2025-05-06 21:10 ` patchwork-bot+netdevbpf

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=55e5aab0-6aa7-4b79-908a-5cbfdc7bd7cd@kernel.org \
    --to=qmo@kernel.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=gthelen@google.com \
    --cc=irogers@google.com \
    --cc=maheshb@google.com \
    --cc=minhanhdn@google.com \
    --cc=sharmasagarika@google.com \
    --cc=tadakentaso@gmail.com \
    --cc=xuanyao@google.com \
    --cc=zhuyifei@google.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