From: "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
Michael Ellerman <mpe@ellerman.id.au>,
Sandipan Das <sandipan@linux.ibm.com>,
Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Cc: linuxppc-dev@lists.ozlabs.org, bpf@vger.kernel.org,
Jiri Olsa <jolsa@redhat.com>,
netdev@vger.kernel.org
Subject: Re: bpf jit PPC64 (BE) test_verifier PTR_TO_STACK store/load failure
Date: Wed, 13 Mar 2019 19:21:18 +0530 [thread overview]
Message-ID: <1552484985.k18yl73ww6.naveen@linux.ibm.com> (raw)
In-Reply-To: <xuny4l87qc2v.fsf@redhat.com>
Hi,
Yauheni Kaliuta wrote:
> Hi!
>
> I found a failure:
>
> ```
> # ./test_verifier 722
> #722/u PTR_TO_STACK store/load FAIL retval -1 != -87117812
> 0: (bf) r1 = r10
> 1: (07) r1 += -10
> 2: (7a) *(u64 *)(r1 +2) = -87117812
> 3: (79) r0 = *(u64 *)(r1 +2)
> 4: (95) exit
> processed 5 insns (limit 131072), stack depth 8
> #722/p PTR_TO_STACK store/load FAIL retval -1 != -87117812
> 0: (bf) r1 = r10
> 1: (07) r1 += -10
> 2: (7a) *(u64 *)(r1 +2) = -87117812
> 3: (79) r0 = *(u64 *)(r1 +2)
> 4: (95) exit
> processed 5 insns (limit 131072), stack depth 8
> Summary: 0 PASSED, 0 SKIPPED, 2 FAILED
> ```
>
> The reason is in the JIT. The code is jitted into:
>
> [...]
> d00000000580e7f8: f9 23 00 00 std r9,0(r3)
> d00000000580e7fc: e9 03 00 02 lwa r8,0(r3)
> [...]
>
> so, it stores DW to the location r3, but loads W, i.e. in BE it is:
>
> saves
> r3: FF FF FF FF FA CE B0 0C
> loads
> r3: FF FF FF FF
>
> (in LE it works semicorretly, saves 0C B0 CE FA FF FF FF FF, loads 0C B0 CE FA)
>
> This is because of the handling of the +2 offset. For stores it is:
>
>
> #define PPC_STD(r, base, i) EMIT(PPC_INST_STD | ___PPC_RS(r) |
> \
> ___PPC_RA(base) | ((i) & 0xfffc))
>
> and for loads
> #define PPC_LD(r, base, i) EMIT(PPC_INST_LD | ___PPC_RT(r) | \
> ___PPC_RA(base) | IMM_L(i))
> #define IMM_L(i) ((uintptr_t)(i) & 0xffff)
>
> So, in the load case the offset +2 (immediate value) is not
> masked and turns the instruction to lwa instead of ld.
Indeed -- good catch and analysis!
>
>
> Would it be correct to & 0xfffc the immediate value as well?
Yes, I think that would be the right fix.
>
> BTW, the full run on big endian:
>
> Summary: 1190 PASSED, 125 SKIPPED, 4 FAILED
Thanks for pointing that out, I'll look into these failures.
- Naveen
next prev parent reply other threads:[~2019-03-13 13:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-13 10:54 bpf jit PPC64 (BE) test_verifier PTR_TO_STACK store/load failure Yauheni Kaliuta
2019-03-13 13:51 ` Naveen N. Rao [this message]
2019-03-13 22:14 ` Segher Boessenkool
2019-03-15 13:16 ` Naveen N. Rao
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=1552484985.k18yl73ww6.naveen@linux.ibm.com \
--to=naveen.n.rao@linux.ibm.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jolsa@redhat.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=netdev@vger.kernel.org \
--cc=sandipan@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;
as well as URLs for NNTP newsgroup(s).