[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20c593b6f31720a3d24d75e5e5cc3245b67249d1.camel@gmail.com>
Date: Tue, 28 Nov 2023 19:59:01 +0200
From: Eduard Zingerman <eddyz87@...il.com>
To: Daniel Xu <dxu@...uu.xyz>, ndesaulniers@...gle.com, andrii@...nel.org,
nathan@...nel.org, daniel@...earbox.net, ast@...nel.org,
steffen.klassert@...unet.com, antony.antony@...unet.com,
alexei.starovoitov@...il.com, yonghong.song@...ux.dev
Cc: martin.lau@...ux.dev, song@...nel.org, john.fastabend@...il.com,
kpsingh@...nel.org, sdf@...gle.com, haoluo@...gle.com, jolsa@...nel.org,
trix@...hat.com, bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev, devel@...ux-ipsec.org, netdev@...r.kernel.org
Subject: Re: [PATCH ipsec-next v2 3/6] libbpf: Add BPF_CORE_WRITE_BITFIELD()
macro
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 bitfield
> 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 also
> 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 to
> to have an inverse helper for writing.
>
> [0]: https://reviews.llvm.org/D133361
> From: Eduard Zingerman <eddyz87@...il.com>
>
> Signed-off-by: Daniel Xu <dxu@...uu.xyz>
> ---
Could you please also add a selftest (or several) using __retval()
annotation for this macro?
Powered by blists - more mailing lists