From: Ilya Leoshkevich <iii@linux.ibm.com>
To: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>
Cc: bpf@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Yauheni Kaliuta <yauheni.kaliuta@redhat.com>,
Ilya Leoshkevich <iii@linux.ibm.com>
Subject: [PATCH RFC bpf-next 2/5] bpf: Make adjust_insn_aux_data() accept variable number of old insns
Date: Thu, 10 Sep 2020 01:34:36 +0200 [thread overview]
Message-ID: <20200909233439.3100292-3-iii@linux.ibm.com> (raw)
In-Reply-To: <20200909233439.3100292-1-iii@linux.ibm.com>
Since this changes the function's meaning, rename it to
adjust_insns_aux_data(). The way this function used to be implemented
for a single insn is somewhat tricky, and the new version preserves
this behavior:
1. For both fast and slow paths, populate zext_dst at [off, off +
cnt_old) positions from insns at [off + cnt - cnt_old, off + cnt)
positions. On the fast path, this produces identical insn_aux_data
and insnsi offsets. On the slow path the offsets are different, but
they will be fixed up later.
2. If the prog size did not change, return (fast path).
3. Preserve all the aux data for the leading insns.
4. Preserve all the aux data for the trailing insns, including what has
been produced during step 1. This is done by memcpying it to a
different offset, which corrects the difference between insn_aux_data
and insnsi offsets.
5. Populate seen and zext_dst for the remaining insns.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
---
kernel/bpf/verifier.c | 33 +++++++++++++++++++--------------
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index dd0b138ee382..077919ac3826 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -9572,25 +9572,29 @@ static void convert_pseudo_ld_imm64(struct bpf_verifier_env *env)
insn->src_reg = 0;
}
-/* single env->prog->insni[off] instruction was replaced with the range
- * insni[off, off + cnt). Adjust corresponding insn_aux_data by copying
- * [0, off) and [off, end) to new locations, so the patched range stays zero
+/* Instructions from the range env->prog->insni[off, off + cnt_old) were
+ * replaced with the range insni[off, off + cnt). Adjust corresponding
+ * insn_aux_data by copying [0, off) and [off, end) to new locations, so the
+ * patched range stays zero.
*/
-static int adjust_insn_aux_data(struct bpf_verifier_env *env,
- struct bpf_prog *new_prog, u32 off, u32 cnt)
+static int adjust_insns_aux_data(struct bpf_verifier_env *env,
+ struct bpf_prog *new_prog, u32 off,
+ u32 cnt_old, u32 cnt)
{
struct bpf_insn_aux_data *new_data, *old_data = env->insn_aux_data;
struct bpf_insn *insn = new_prog->insnsi;
u32 prog_len;
int i;
- /* aux info at OFF always needs adjustment, no matter fast path
- * (cnt == 1) is taken or not. There is no guarantee INSN at OFF is the
- * original insn at old prog.
+ /* aux infos at [off, off + cnt_old) need adjustment even on the fast
+ * path (cnt == cnt_old). There is no guarantee the insns at [off,
+ * off + cnt_old) are the original ones at old prog.
*/
- old_data[off].zext_dst = insn_has_def32(env, insn + off + cnt - 1);
+ for (i = off; i < off + cnt_old; i++)
+ old_data[i].zext_dst =
+ insn_has_def32(env, insn + i + cnt - cnt_old);
- if (cnt == 1)
+ if (cnt == cnt_old)
return 0;
prog_len = new_prog->len;
new_data = vzalloc(array_size(prog_len,
@@ -9598,9 +9602,10 @@ static int adjust_insn_aux_data(struct bpf_verifier_env *env,
if (!new_data)
return -ENOMEM;
memcpy(new_data, old_data, sizeof(struct bpf_insn_aux_data) * off);
- memcpy(new_data + off + cnt - 1, old_data + off,
- sizeof(struct bpf_insn_aux_data) * (prog_len - off - cnt + 1));
- for (i = off; i < off + cnt - 1; i++) {
+ memcpy(new_data + off + cnt - cnt_old, old_data + off,
+ sizeof(struct bpf_insn_aux_data) *
+ (prog_len - off - cnt + cnt_old));
+ for (i = off; i < off + cnt - cnt_old; i++) {
new_data[i].seen = env->pass_cnt;
new_data[i].zext_dst = insn_has_def32(env, insn + i);
}
@@ -9636,7 +9641,7 @@ static struct bpf_prog *bpf_patch_insn_data(struct bpf_verifier_env *env, u32 of
env->insn_aux_data[off].orig_idx);
return NULL;
}
- if (adjust_insn_aux_data(env, new_prog, off, len))
+ if (adjust_insns_aux_data(env, new_prog, off, 1, len))
return NULL;
adjust_subprog_starts(env, off, len);
return new_prog;
--
2.25.4
next prev parent reply other threads:[~2020-09-10 2:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-09 23:34 [PATCH RFC bpf-next 0/5] Do not include the original insn in zext patchlet Ilya Leoshkevich
2020-09-09 23:34 ` [PATCH RFC bpf-next 1/5] bpf: Make bpf_patch_insn_single() accept variable number of old insns Ilya Leoshkevich
2020-09-09 23:34 ` Ilya Leoshkevich [this message]
2020-09-09 23:34 ` [PATCH RFC bpf-next 3/5] bpf: Make adjust_subprog_starts() " Ilya Leoshkevich
2020-09-09 23:34 ` [PATCH RFC bpf-next 4/5] bpf: Make bpf_patch_insn_data() " Ilya Leoshkevich
2020-09-09 23:34 ` [PATCH RFC bpf-next 5/5] bpf: Do not include the original insn in zext patchlet Ilya Leoshkevich
2020-09-10 6:59 ` Yauheni Kaliuta
2020-09-10 9:18 ` Ilya Leoshkevich
2020-09-11 0:25 ` Alexei Starovoitov
2020-09-11 6:33 ` Yauheni Kaliuta
2020-09-11 12:58 ` Ilya Leoshkevich
2020-09-29 20:03 ` Ilya Leoshkevich
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=20200909233439.3100292-3-iii@linux.ibm.com \
--to=iii@linux.ibm.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=yauheni.kaliuta@redhat.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