All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
To: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	bpf@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>
Subject: Re: [PATCH RFC bpf-next 5/5] bpf: Do not include the original insn in zext patchlet
Date: Thu, 10 Sep 2020 09:59:41 +0300	[thread overview]
Message-ID: <xuny363qazhe.fsf@redhat.com> (raw)
In-Reply-To: <20200909233439.3100292-6-iii@linux.ibm.com> (Ilya Leoshkevich's message of "Thu, 10 Sep 2020 01:34:39 +0200")

Hi, Ilya!

Cool, thanks!

Shouldn't the rnd patch be done the same way for completeness?
Even if it is unlikely there to hit the problem.

>>>>> On Thu, 10 Sep 2020 01:34:39 +0200, Ilya Leoshkevich  wrote:

 > If the original insn is a jump, then it is not subjected to branch
 > adjustment, which is incorrect. As discovered by Yauheni in

 > https://lore.kernel.org/bpf/20200903140542.156624-1-yauheni.kaliuta@redhat.com/

 > this causes `test_progs -t global_funcs` failures on s390.

 > Most likely, the current code includes the original insn in the
 > patchlet, because there was no infrastructure to insert new insns, only
 > to replace the existing ones. Now that bpf_patch_insns_data() can do
 > insertions, stop including the original insns in zext patchlets.

 > Fixes: a4b1d3c1ddf6 ("bpf: verifier: insert zero extension according
 > to analysis result")
 > Reported-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
 > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
 > ---
 >  kernel/bpf/verifier.c | 20 +++++++++++---------
 >  1 file changed, 11 insertions(+), 9 deletions(-)

 > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
 > index 17c2e926e436..64a04953c631 100644
 > --- a/kernel/bpf/verifier.c
 > +++ b/kernel/bpf/verifier.c
 > @@ -9911,7 +9911,7 @@ static int opt_remove_nops(struct bpf_verifier_env *env)
 >  static int opt_subreg_zext_lo32_rnd_hi32(struct bpf_verifier_env *env,
 >  					 const union bpf_attr *attr)
 >  {
 > -	struct bpf_insn *patch, zext_patch[2], rnd_hi32_patch[4];
 > +	struct bpf_insn *patch, zext_patch, rnd_hi32_patch[4];
 >  	struct bpf_insn_aux_data *aux = env->insn_aux_data;
 >  	int i, patch_len, delta = 0, len = env->prog->len;
 >  	struct bpf_insn *insns = env->prog->insnsi;
 > @@ -9919,13 +9919,14 @@ static int opt_subreg_zext_lo32_rnd_hi32(struct bpf_verifier_env *env,
 >  	bool rnd_hi32;
 
 >  	rnd_hi32 = attr->prog_flags & BPF_F_TEST_RND_HI32;
 > -	zext_patch[1] = BPF_ZEXT_REG(0);
 > +	zext_patch = BPF_ZEXT_REG(0);
 >  	rnd_hi32_patch[1] = BPF_ALU64_IMM(BPF_MOV, BPF_REG_AX, 0);
 >  	rnd_hi32_patch[2] = BPF_ALU64_IMM(BPF_LSH, BPF_REG_AX, 32);
 >  	rnd_hi32_patch[3] = BPF_ALU64_REG(BPF_OR, 0, BPF_REG_AX);
 >  	for (i = 0; i < len; i++) {
 >  		int adj_idx = i + delta;
 >  		struct bpf_insn insn;
 > +		int len_old = 1;
 
 >  		insn = insns[adj_idx];
 >  		if (!aux[adj_idx].zext_dst) {
 > @@ -9968,20 +9969,21 @@ static int opt_subreg_zext_lo32_rnd_hi32(struct bpf_verifier_env *env,
 >  		if (!bpf_jit_needs_zext())
 >  			continue;
 
 > -		zext_patch[0] = insn;
 > -		zext_patch[1].dst_reg = insn.dst_reg;
 > -		zext_patch[1].src_reg = insn.dst_reg;
 > -		patch = zext_patch;
 > -		patch_len = 2;
 > +		zext_patch.dst_reg = insn.dst_reg;
 > +		zext_patch.src_reg = insn.dst_reg;
 > +		patch = &zext_patch;
 > +		patch_len = 1;
 > +		adj_idx++;
 > +		len_old = 0;
 >  apply_patch_buffer:
 > -		new_prog = bpf_patch_insns_data(env, adj_idx, 1, patch,
 > +		new_prog = bpf_patch_insns_data(env, adj_idx, len_old, patch,
 >  						patch_len);
 >  		if (!new_prog)
 >  			return -ENOMEM;
 env-> prog = new_prog;
 >  		insns = new_prog->insnsi;
 >  		aux = env->insn_aux_data;
 > -		delta += patch_len - 1;
 > +		delta += patch_len - len_old;
 >  	}
 
 >  	return 0;
 > -- 

 > 2.25.4


-- 
WBR,
Yauheni Kaliuta


  reply	other threads:[~2020-09-10  7:02 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 ` [PATCH RFC bpf-next 2/5] bpf: Make adjust_insn_aux_data() " Ilya Leoshkevich
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 [this message]
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=xuny363qazhe.fsf@redhat.com \
    --to=yauheni.kaliuta@redhat.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=iii@linux.ibm.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 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.