From: Leon Hwang <leon.hwang@linux.dev>
To: Eduard Zingerman <eddyz87@gmail.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Jiri Olsa <jolsa@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Quentin Monnet <qmo@kernel.org>, Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel-patches-bot@fb.com
Subject: Re: [PATCH bpf-next v11 03/10] bpf: Introduce global percpu data
Date: Tue, 11 Aug 2026 12:16:11 +0800 [thread overview]
Message-ID: <5e8cc9c2-ae36-493b-922f-0d86f253265c@linux.dev> (raw)
In-Reply-To: <8ea2c2ef5a50333c84865d09c860a9617edbda9b.camel@gmail.com>
On 11/8/26 07:22, Eduard Zingerman wrote:
> On Fri, 2026-08-07 at 00:31 +0800, Leon Hwang wrote:
>
> ...
>
>> diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
>> index 440e73e1b11b..f2398749103b 100644
>> --- a/kernel/bpf/fixups.c
>> +++ b/kernel/bpf/fixups.c
>> @@ -1817,6 +1817,43 @@ int bpf_do_misc_fixups(struct bpf_verifier_env *env)
>> goto next_insn;
>> }
>>
>> + if (bpf_jit_supports_percpu_insn() &&
>> + insn->code == (BPF_LD | BPF_IMM | BPF_DW) &&
>> + (insn->src_reg == BPF_PSEUDO_MAP_VALUE ||
>> + insn->src_reg == BPF_PSEUDO_MAP_IDX_VALUE)) {
>> + struct bpf_map *map;
>> +
>> + aux = &env->insn_aux_data[i + delta];
>> + map = env->used_maps[aux->map_index];
>> + if (map->map_type != BPF_MAP_TYPE_PERCPU_ARRAY)
>> + goto next_insn;
>> +
>> + prog->jit_required = true;
>> +
>> + /*
>> + * We are *skipping* first half of ld_imm64 insn
>> + * with 'i++;', patching over second half of it
>> + * with that same half + mov64_percpu_reg insn.
>> + * All because bpf_patch_insn_data() can only
>> + * replace one 8-byte insn, which does not work
>> + * well for ld_imm64 insn.
>> + */
>> +
>> + insn_buf[0] = insn[1];
>> + insn_buf[1] = BPF_MOV64_PERCPU_REG(insn->dst_reg, insn->dst_reg);
>> + cnt = 2;
>
> Hi Leon,
>
> Sorry for joining the discussion so late, but Andrii asked me to take
> a look at the verifier part of the changes. Could you please elaborate
> on what exactly does not work with 16-byte instructions and
> bpf_patch_insn_data()? Note that e.g. 'if (insn->imm == BPF_FUNC_timer_set_callback) {'
> case in the same bpf_do_misc_fixups() applies a patch containing BPF_LD_IMM64().
The BPF_FUNC_timer_set_callback case is different from this patch.
The BPF_FUNC_timer_set_callback case inserts a ld_imm64 insn at the
position of the call insn.
However, this patch is going to insert a mov64_percpu_reg insn after the
ld_imm64 insn.
Since ld_imm64 insn is a 16-byte insn, the new mov64_percpu_reg must sit
after the ld_imm64 insn by 'i++'.
Then, let's look into bpf_patch_insn_data(). bpf_patch_insn_data()
utilizes bpf_patch_insn_single() to insert insns at the position of one
8-byte insn. See memmove(..., + off + 1, ...), the *1* is for one 8-byte
insn. I tried to modify bpf_patch_insn_single() to add 16-byte insn
support, but that looked much complicated against this patch.
Thanks,
Leon
>
> The rest of the patch lgtm.
>
>> +
>> + i++;
>> + new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt);
>> + if (!new_prog)
>> + return -ENOMEM;
>> +
>> + delta += cnt - 1;
>> + env->prog = prog = new_prog;
>> + insn = new_prog->insnsi + i + delta;
>> + goto next_insn;
>> + }
>> +
>> if (insn->code != (BPF_JMP | BPF_CALL))
>> goto next_insn;
>> if (insn->src_reg == BPF_PSEUDO_CALL)
>
> ...
next prev parent reply other threads:[~2026-08-11 4:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 16:31 [PATCH bpf-next v11 00/10] bpf: Introduce global percpu data Leon Hwang
2026-08-06 16:31 ` [PATCH bpf-next v11 01/10] bpf: Drop duplicate blank lines in kernel/bpf/ Leon Hwang
2026-08-06 16:31 ` [PATCH bpf-next v11 02/10] bpf: Factor out check_map_mem_read helper in verifier Leon Hwang
2026-08-10 21:38 ` Eduard Zingerman
2026-08-06 16:31 ` [PATCH bpf-next v11 03/10] bpf: Introduce global percpu data Leon Hwang
2026-08-10 23:22 ` Eduard Zingerman
2026-08-11 4:16 ` Leon Hwang [this message]
2026-08-11 7:54 ` Eduard Zingerman
2026-08-06 16:31 ` [PATCH bpf-next v11 04/10] libbpf: Probe percpu data feature Leon Hwang
2026-08-06 17:05 ` sashiko-bot
2026-08-07 2:26 ` Leon Hwang
2026-08-06 16:31 ` [PATCH bpf-next v11 05/10] libbpf: Add support for global percpu data Leon Hwang
2026-08-06 16:57 ` sashiko-bot
2026-08-07 2:36 ` Leon Hwang
2026-08-06 16:31 ` [PATCH bpf-next v11 06/10] bpftool: Generate skeleton " Leon Hwang
2026-08-06 16:31 ` [PATCH bpf-next v11 07/10] selftests/bpf: Add tests to verify " Leon Hwang
2026-08-06 16:31 ` [PATCH bpf-next v11 08/10] selftests/bpf: Test direct reading/writing read-only percpu_array map Leon Hwang
2026-08-06 16:31 ` [PATCH bpf-next v11 09/10] selftests/bpf: Test verifier log for global percpu data Leon Hwang
2026-08-06 16:31 ` [PATCH bpf-next v11 10/10] selftests/bpf: Verify bpf_iter " Leon Hwang
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=5e8cc9c2-ae36-493b-922f-0d86f253265c@linux.dev \
--to=leon.hwang@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-patches-bot@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=qmo@kernel.org \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.