Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
MIME-Version: 1.0
References: <cover.1701193577.git.dxu@dxuuu.xyz> <ed7920365daf5eff1c82892b57e918d3db786ac7.1701193577.git.dxu@dxuuu.xyz>
 <20c593b6f31720a3d24d75e5e5cc3245b67249d1.camel@gmail.com> <ib27gbqj6c6ilblugm5kalwyfty6h4zujhvykw4a562uorqzjn@6wxeino6q7vk>
In-Reply-To: <ib27gbqj6c6ilblugm5kalwyfty6h4zujhvykw4a562uorqzjn@6wxeino6q7vk>
From:   Andrii Nakryiko <andrii.nakryiko@gmail.com>
Date:   Fri, 1 Dec 2023 11:11:31 -0800
Message-ID: <CAEf4BzbO80kFyFBCUixJ_NGqjJv79i+6oQXz+-jzRE+MaoRYZA@mail.gmail.com>
Subject: Re: [PATCH ipsec-next v2 3/6] libbpf: Add BPF_CORE_WRITE_BITFIELD() macro
To:     Daniel Xu <dxu@dxuuu.xyz>
Cc:     Eduard Zingerman <eddyz87@gmail.com>, ndesaulniers@google.com,
        andrii@kernel.org, nathan@kernel.org, daniel@iogearbox.net,
        ast@kernel.org, steffen.klassert@secunet.com,
        antony.antony@secunet.com, alexei.starovoitov@gmail.com,
        yonghong.song@linux.dev, martin.lau@linux.dev, song@kernel.org,
        john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com,
        haoluo@google.com, jolsa@kernel.org, trix@redhat.com,
        bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
        llvm@lists.linux.dev, devel@linux-ipsec.org, netdev@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Nov 30, 2023 at 5:33=E2=80=AFPM Daniel Xu <dxu@dxuuu.xyz> wrote:
>
> On Tue, Nov 28, 2023 at 07:59:01PM +0200, Eduard Zingerman wrote:
> > On Tue, 2023-11-28 at 10:54 -0700, Daniel Xu wrote:
> > > Similar to reading from CO-RE bitfields, we need a CO-RE aware bitfie=
ld
> > > writing wrapper to make the verifier happy.
> > >
> > > Two alternatives to this approach are:
> > >
> > > 1. Use the upcoming `preserve_static_offset` [0] attribute to disable
> > >    CO-RE on specific structs.
> > > 2. Use broader byte-sized writes to write to bitfields.
> > >
> > > (1) is a bit a bit hard to use. It requires specific and
> > > not-very-obvious annotations to bpftool generated vmlinux.h. It's als=
o
> > > not generally available in released LLVM versions yet.
> > >
> > > (2) makes the code quite hard to read and write. And especially if
> > > BPF_CORE_READ_BITFIELD() is already being used, it makes more sense t=
o
> > > to have an inverse helper for writing.
> > >
> > > [0]: https://reviews.llvm.org/D133361
> > > From: Eduard Zingerman <eddyz87@gmail.com>
> > >
> > > Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
> > > ---
> >
> > Could you please also add a selftest (or several) using __retval()
> > annotation for this macro?
>
> Good call about adding tests -- I found a few bugs with the code from
> the other thread. But boy did they take a lot of brain cells to figure
> out.
>
> There was some 6th grade algebra involved too -- I'll do my best to
> explain it in the commit msg for v3.
>
>
> Here are the fixes in case you are curious:
>
> diff --git a/tools/lib/bpf/bpf_core_read.h b/tools/lib/bpf/bpf_core_read.=
h
> index 7a764f65d299..8f02c558c0ff 100644
> --- a/tools/lib/bpf/bpf_core_read.h
> +++ b/tools/lib/bpf/bpf_core_read.h
> @@ -120,7 +120,9 @@ enum bpf_enum_value_kind {
>         unsigned int byte_size =3D __CORE_RELO(s, field, BYTE_SIZE);     =
 \
>         unsigned int lshift =3D __CORE_RELO(s, field, LSHIFT_U64);       =
 \
>         unsigned int rshift =3D __CORE_RELO(s, field, RSHIFT_U64);       =
 \
> -       unsigned int bit_size =3D (rshift - lshift);                     =
 \
> +       unsigned int bit_size =3D (64 - rshift);                         =
 \
> +       unsigned int hi_size =3D lshift;                                 =
 \
> +       unsigned int lo_size =3D (rshift - lshift);                      =
 \

nit: let's drop unnecessary ()

>         unsigned long long nval, val, hi, lo;                           \
>                                                                         \
>         asm volatile("" : "+r"(p));                                     \
> @@ -131,13 +133,13 @@ enum bpf_enum_value_kind {
>         case 4: val =3D *(unsigned int *)p; break;                       =
 \
>         case 8: val =3D *(unsigned long long *)p; break;                 =
 \
>         }                                                               \
> -       hi =3D val >> (bit_size + rshift);                               =
 \
> -       hi <<=3D bit_size + rshift;                                      =
 \
> -       lo =3D val << (bit_size + lshift);                               =
 \
> -       lo >>=3D bit_size + lshift;                                      =
 \
> +       hi =3D val >> (64 - hi_size);                                    =
 \
> +       hi <<=3D 64 - hi_size;                                           =
 \
> +       lo =3D val << (64 - lo_size);                                    =
 \
> +       lo >>=3D 64 - lo_size;                                           =
 \
>         nval =3D new_val;                                                =
 \
> -       nval <<=3D lshift;                                               =
 \
> -       nval >>=3D rshift;                                               =
 \
> +       nval <<=3D (64 - bit_size);                                      =
 \
> +       nval >>=3D (64 - bit_size - lo_size);                            =
 \
>         val =3D hi | nval | lo;                                          =
 \

this looks.. unusual. I'd imagine we calculate a mask, mask out bits
we are replacing, and then OR with new values, roughly (assuming all
the right left/right shift values and stuff)

/* clear bits */
val &=3D ~(bitfield_mask << shift);
/* set bits */
val |=3D (nval & bitfield_mask) << shift;

?

>         switch (byte_size) {                                            \
>         case 1: *(unsigned char *)p      =3D val; break;                 =
 \
>
>
> Thanks,
> Daniel