BPF List
 help / color / mirror / Atom feed
From: "Alexis Lothoré" <alexis.lothore@bootlin.com>
To: Alan Maguire <alan.maguire@oracle.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>, Mykola Lysenko <mykolal@fb.com>,
	Shuah Khan <shuah@kernel.org>
Cc: ebpf@linuxfoundation.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH bpf-next 3/4] selftests/bpf: add proper section name to bpf prog and rename it
Date: Thu, 1 Aug 2024 12:00:34 +0200	[thread overview]
Message-ID: <263cd78b-0392-45d4-a13c-b2b0463c4c8c@bootlin.com> (raw)
In-Reply-To: <e8b88d27-4e85-46f1-8ed4-df883abc8a51@oracle.com>

On 8/1/24 10:35, Alan Maguire wrote:
> On 31/07/2024 11:38, Alexis Lothoré (eBPF Foundation) wrote:
>> test_skb_cgroup_id_kern.c is currently involved in a manual test. In its
>> current form, it can not be used with the auto-generated skeleton APIs,
>> because the section name is not valid to allow libbpf to deduce the program
>> type.
>>
>> Update section name to allow skeleton APIs usage. Also rename the program
>> name to make it shorter and more straighforward regarding the API it is
>> testing. While doing so, make sure that test_skb_cgroup_id.sh passes to get
>> a working reference before converting it to test_progs
>> - update the obj name
>> - fix loading issue (verifier rejecting the program when loaded through tc,
>>   because of map not found), by preloading the whole obj with bpftool
>>
>> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> 
> Reviewed-by: Alan Maguire <alan.maguire@oracle.com>

[...]

>>  	tc qdisc add dev ${TEST_IF} clsact
>> -	tc filter add dev ${TEST_IF} egress bpf obj ${BPF_PROG_OBJ} \
>> -		sec ${BPF_PROG_SECTION} da
>> +	mkdir -p /sys/fs/bpf/${BPF_PROG_PIN}
>> +	bpftool prog loadall ${BPF_PROG_OBJ} /sys/fs/bpf/${BPF_PROG_PIN} type tc
>> +	tc filter add dev ${TEST_IF} egress bpf da object-pinned \
>> +		/sys/fs/bpf/${BPF_PROG_PIN}/${BPF_PROG_NAME}
>>
> 
> Just out of curiosity; did you find that the pin is needed? I would have
> thought tc attach would be enough to keep the program aroud.

That's more because that's the only way I found to make the filter addition
work. With the current command, the tc command fails because of the verifier
rejecting the program:

Verifier analysis:

func#0 @0
0: R1=ctx() R10=fp0
0: (bf) r6 = r1                       ; R1=ctx() R6_w=ctx()
1: (b4) w1 = 0                        ; R1_w=0
2: (63) *(u32 *)(r10 -4) = r1
mark_precise: frame0: last_idx 2 first_idx 0 subseq_idx -1
mark_precise: frame0: regs=r1 stack= before 1: (b4) w1 = 0
3: R1_w=0 R10=fp0 fp-8=0000????
3: (bf) r1 = r6                       ; R1_w=ctx() R6_w=ctx()
4: (b4) w2 = 0                        ; R2_w=0
5: (85) call bpf_skb_ancestor_cgroup_id#83    ; R0_w=scalar()
6: (7b) *(u64 *)(r10 -16) = r0        ; R0_w=scalar(id=1) R10=fp0
fp-16_w=scalar(id=1)
7: (bf) r2 = r10                      ; R2_w=fp0 R10=fp0
8: (07) r2 += -4                      ; R2_w=fp-4
9: (bf) r3 = r10                      ; R3_w=fp0 R10=fp0
10: (07) r3 += -16                    ; R3_w=fp-16
11: (18) r1 = 0x0                     ; R1_w=0
13: (b7) r4 = 0                       ; R4_w=0
14: (85) call bpf_map_update_elem#2
R1 type=scalar expected=map_ptr
processed 14 insns (limit 1000000) max_states_per_insn 0 total_states 0
peak_states 0 mark_read 0

(I also tried to remove the sec argument from the tc commandline, in case it
could allow tc to load everything, but the issue remains the same)

IIUC the verifier output, there's an issue with the variable representing the map.
When stracing the tc filter add command, I indeed see the BPF_PROG_LOAD syscall
but no BPF_MAP_CREATE at all, so I assumed tc did not read/create the map
correctly. That's why I used bpftool to make sure everything is loaded, but as a
consequence I need to provide a pin path when using load/loadall. But maybe I am
missing something ?

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


  reply	other threads:[~2024-08-01 10:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-31 10:38 [PATCH bpf-next 0/4] selftests/bpf: convert three other cgroup tests to test_progs Alexis Lothoré (eBPF Foundation)
2024-07-31 10:38 ` [PATCH bpf-next 1/4] selftests/bpf: convert get_current_cgroup_id_user " Alexis Lothoré (eBPF Foundation)
2024-07-31 17:23   ` Alan Maguire
2024-07-31 18:53     ` Alexis Lothoré
2024-08-01  8:17       ` Alan Maguire
2024-08-01  8:57         ` Alexis Lothoré
2024-07-31 10:38 ` [PATCH bpf-next 2/4] selftests/bpf: convert test_cgroup_storage " Alexis Lothoré (eBPF Foundation)
2024-08-01  8:27   ` Alan Maguire
2024-08-01  9:21     ` Alexis Lothoré
2024-08-06 12:38       ` Alan Maguire
2024-07-31 10:38 ` [PATCH bpf-next 3/4] selftests/bpf: add proper section name to bpf prog and rename it Alexis Lothoré (eBPF Foundation)
2024-08-01  8:35   ` Alan Maguire
2024-08-01 10:00     ` Alexis Lothoré [this message]
2024-08-06 12:33       ` Alan Maguire
2024-08-06 17:24         ` Alexis Lothoré
2024-07-31 10:38 ` [PATCH bpf-next 4/4] selftests/bpf: convert test_skb_cgroup_id_user to test_progs Alexis Lothoré (eBPF Foundation)
2024-08-01  8:49   ` Alan Maguire
2024-08-01 10:12     ` Alexis Lothoré
2024-08-06 12:26       ` Alan Maguire

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=263cd78b-0392-45d4-a13c-b2b0463c4c8c@bootlin.com \
    --to=alexis.lothore@bootlin.com \
    --cc=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=ebpf@linuxfoundation.org \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mykolal@fb.com \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=yonghong.song@linux.dev \
    /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