All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Chaignon <paul@cilium.io>
To: Yonghong Song <yhs@fb.com>
Cc: bpf@vger.kernel.org, Martynas Pumputis <m@lambda.lt>
Subject: Re: R11 is invalid with LLVM 12 and later
Date: Wed, 11 Aug 2021 18:54:46 +0200	[thread overview]
Message-ID: <20210811165446.GA30403@Mem> (raw)
In-Reply-To: <d1054971-0cd5-5698-c895-f412d1b47bb2@fb.com>

On Mon, Aug 09, 2021 at 11:31:48PM -0700, Yonghong Song wrote:
> On 8/9/21 3:53 PM, Yonghong Song wrote:
> > On 8/9/21 8:12 AM, Paul Chaignon wrote:

[...]

> > > LLVM 12.0.1 and latest LLVM sources (e.g., commit 2b4a1d4b from today)
> > > have the same issue. We've bisected it to LLVM commit 552c6c23
> > > ("PR44406: Follow behavior of array bound constant folding in more
> > > recent versions of GCC."), but that could just be the commit where
> > > the regression was exposed in Cilium's case.
> 
> The above commit is indeed responsible. With the above commit,
> the variable length array compile time evaluation becomes conservative.
> For cilium function dsr_reply_icmp4 in nodeport.h
>   const __u32 l3_max = MAX_IPOPTLEN + sizeof(*ip4) + orig_dgram;
>   __u8 tmp[l3_max];
> 
> I didn't try to compile with/without the above commit, the following
> is the thesis.
> 
> Before the above commit, llvm evaluates the expression
>   MAX_IPOPTLEN + sizeof(*ip4) + orig_dgram
> and concludes that l3_max is a constant so tmp can be allocated
> on stack with fixed size.
> 
> With the above commit, llvm becomes conservative to evaluate
> the expression at compile time. So above l3_max becomes a
> non-constant variable and tmp becomes a variable length
> array. Since it becomes a variable length array, the
> hidden stack pointer "r11" is used and this caused a problem
> in verifier.
> 
> To workaround the issue, simply define "tmp" with
>    __u8 tmp[68];

Thanks Yonghong!  I've tested this workaround on the Cilium codebase
with all of our tested configurations.  I'm not seeing this R11 issue in
this BPF program or anywhere else anymore.

> But that is not for from user experience. I guess we can do:
>   1. for BPF target, let us still do aggressive constant folding
>      in compile time in clang, basically restores to pre-commit-552c6c23
>      level for BPF programs.
>   2. provide an error message if r11 is generated in final code.
> 
> Will come back to this thread once I got concrete patches. Thanks!

I'm happy to run any patch you have through the Cilium CI if that helps.

> 
> > > 
> > > -- 
> > > Paul
> > > 

  reply	other threads:[~2021-08-11 16:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-09 15:12 R11 is invalid with LLVM 12 and later Paul Chaignon
2021-08-09 22:53 ` Yonghong Song
2021-08-10  6:31   ` Yonghong Song
2021-08-11 16:54     ` Paul Chaignon [this message]
2021-08-12  1:23       ` Yonghong Song

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=20210811165446.GA30403@Mem \
    --to=paul@cilium.io \
    --cc=bpf@vger.kernel.org \
    --cc=m@lambda.lt \
    --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 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.