[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5F4DEFB2-5F5A-4703-B5E5-BBCE05CD3651@fb.com>
Date: Sat, 22 Jan 2022 01:30:30 +0000
From: Song Liu <songliubraving@...com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
CC: Song Liu <song@...nel.org>, bpf <bpf@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
"Alexei Starovoitov" <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
"Andrii Nakryiko" <andrii@...nel.org>,
Kernel Team <Kernel-team@...com>,
"Peter Zijlstra" <peterz@...radead.org>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH v6 bpf-next 6/7] bpf: introduce bpf_prog_pack allocator
> On Jan 21, 2022, at 5:12 PM, Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
>
> On Fri, Jan 21, 2022 at 5:01 PM Song Liu <songliubraving@...com> wrote:
>>
>> In this way, we need to allocate rw_image here, and free it in
>> bpf_jit_comp.c. This feels a little weird to me, but I guess that
>> is still the cleanest solution for now.
>
> You mean inside bpf_jit_binary_alloc?
> That won't be arch independent.
> It needs to be split into generic piece that stays in core.c
> and callbacks like bpf_jit_fill_hole_t
> or into multiple helpers with prep in-between.
> Don't worry if all archs need to be touched.
How about we introduce callback bpf_jit_set_header_size_t? Then we
can split x86's jit_fill_hole() into two functions, one to fill the
hole, the other to set size. The rest of the logic gonna stay the same.
Archs that do not use bpf_prog_pack won't need bpf_jit_set_header_size_t.
Thanks,
Song
Powered by blists - more mailing lists