bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Li <vincent.mc.li@gmail.com>
To: Yonghong Song <yhs@fb.com>
Cc: bpf@vger.kernel.org
Subject: Re: R1 invalid mem access 'inv'
Date: Thu, 15 Jul 2021 18:33:46 -0700	[thread overview]
Message-ID: <CAK3+h2xP0_9WgqDbfRC-rzkOSv2FKKsNjHmPvTFy9xALwgw3AA@mail.gmail.com> (raw)
In-Reply-To: <efbbc4bc-5513-82d4-4f00-28c690653509@fb.com>

Thanks Yonghong for looking into this.

On Tue, Jul 13, 2021 at 8:46 AM Yonghong Song <yhs@fb.com> wrote:
>
>
>
> On 7/12/21 4:38 PM, Vincent Li wrote:
> > Hi Yonghong,
> >
> >
> >
> > On Fri, Jun 18, 2021 at 12:58 PM Vincent Li <vincent.mc.li@gmail.com> wrote:
> >>
> >> Hi Yonghong,
> >>
> >> I attached the full verifier log and BPF bytecode just in case it is
> >> obvious to you, if it is not, that is ok. I tried to make sense out of
> >> it and I failed due to my limited knowledge about BPF :)
> >>
> >
> > I followed your clue on investigating how fp-200=pkt changed to
> > fp-200=inv in https://github.com/cilium/cilium/issues/16517#issuecomment-873522146
> > with previous attached complete bpf verifier log and bpf bytecode, it
> > eventually comes to following
> >
> > 0000000000004948 :
> >      2345: bf a3 00 00 00 00 00 00 r3 = r10
> >      2346: 07 03 00 00 d0 ff ff ff r3 += -48
> >      2347: b7 08 00 00 06 00 00 00 r8 = 6
> > ; return ctx_store_bytes(ctx, off, mac, ETH_ALEN, 0);
> >      2348: bf 61 00 00 00 00 00 00 r1 = r6
> >      2349: b7 02 00 00 00 00 00 00 r2 = 0
> >      2350: b7 04 00 00 06 00 00 00 r4 = 6
> >      2351: b7 05 00 00 00 00 00 00 r5 = 0
> >      2352: 85 00 00 00 09 00 00 00 call 9
> >      2353: 67 00 00 00 20 00 00 00 r0 <<= 32
> >      2354: c7 00 00 00 20 00 00 00 r0 s>>= 32
> > ; if (eth_store_daddr(ctx, (__u8 *) &vtep_mac.addr, 0) < 0)
> >      2355: c5 00 54 00 00 00 00 00 if r0 s< 0 goto +84
> >
> > my new code is eth_store_daddr(ctx, (__u8 *) &vtep_mac.addr, 0) < 0;
> > that is what i copied from other part of cilium code, eth_store_daddr
> > is:
> >
> > static __always_inline int eth_store_daddr(struct __ctx_buff *ctx,
> >
> >                                             const __u8 *mac, int off)
> > {
> > #if !CTX_DIRECT_WRITE_OK
> >          return eth_store_daddr_aligned(ctx, mac, off);
> > #else
> > ......
> > }
> >
> > and eth_store_daddr_aligned is
> >
> > static __always_inline int eth_store_daddr_aligned(struct __ctx_buff *ctx,
> >
> >                                                     const __u8 *mac, int off)
> > {
> >          return ctx_store_bytes(ctx, off, mac, ETH_ALEN, 0);
> > }
> >
> > Joe  from Cilium raised an interesting question on why the compiler
> > put ctx_store_bytes() before  if (eth_store_daddr(ctx, (__u8 *)
> > &vtep_mac.addr, 0) < 0),
> > that seems to have  fp-200=pkt changed to fp-200=inv, and indeed if I
> > skip the eth_store_daddr_aligned call, the issue is resolved, do you
> > have clue on why compiler does that?
>
> This is expected. After inlining, you got
>     if (ctx_store_bytes(...) < 0) ...
>
> So you need to do
>     ctx_store_bytes(...)
> first and then do the if condition.
>

I got workaround which is not to use eth_store_daddr_aligned, but use
__builtin_memcpy() according to
cilium commit 9c857217834 (bpf: optimized memcpy/memzero with dw-wide copies)

> Looking at the issue at https://github.com/cilium/cilium/issues/16517,
> the reason seems due to xdp_store_bytes/skb_store_bytes.
> When these helpers write some data into the stack based buffer, they
> invalidate some stack contents. I don't know whether it is a false
> postive case or not, i.e., the verifier invalidates the wrong stack
> location conservatively. This needs further investigation.
>
glad to know it is not something silly that I am doing, hope it can be
figured out eventually someday :)

>
> >
> > I have more follow-up in https://github.com/cilium/cilium/issues/16517
> > if you are interested to know the full picture.
> >
> > Appreciate it very much if you have time to look at it :)
> >
> > Vincent
> >

  reply	other threads:[~2021-07-16  1:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-17  0:05 R1 invalid mem access 'inv' Vincent Li
2021-06-17  6:02 ` Yonghong Song
2021-06-17 14:19   ` Vincent Li
2021-06-17 16:32     ` Yonghong Song
2021-06-17 22:19       ` Vincent Li
2021-06-18  0:51         ` Yonghong Song
2021-06-18  3:58           ` Vincent Li
2021-06-18  4:15             ` Vincent Li
     [not found]               ` <CAK3+h2xv-EZH9afEymGqKdwHozHHu=XHJYKispFSixYxz7YVLQ@mail.gmail.com>
2021-07-12 23:38                 ` Vincent Li
2021-07-13 15:46                   ` Yonghong Song
2021-07-16  1:33                     ` Vincent Li [this message]
2021-09-19  1:46                       ` Vincent Li

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=CAK3+h2xP0_9WgqDbfRC-rzkOSv2FKKsNjHmPvTFy9xALwgw3AA@mail.gmail.com \
    --to=vincent.mc.li@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=yhs@fb.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).