[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <90BE2D77-DA7B-461C-94BD-A6BBB5775E12@fb.com>
Date: Thu, 31 Mar 2022 00:31:46 +0000
From: Song Liu <songliubraving@...com>
To: Thomas Gleixner <tglx@...utronix.de>
CC: Song Liu <song@...nel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
X86 ML <x86@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Kernel Team <Kernel-team@...com>,
Andrew Morton <akpm@...ux-foundation.org>,
Paul Menzel <pmenzel@...gen.mpg.de>,
"rick.p.edgecombe@...el.com" <rick.p.edgecombe@...el.com>
Subject: Re: [PATCH bpf 4/4] bpf: use __vmalloc_node_range() with
VM_TRY_HUGE_VMAP for bpf_prog_pack
> On Mar 30, 2022, at 5:00 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
>
> On Wed, Mar 30 2022 at 15:56, Song Liu wrote:
>> We cannot yet savely enable HAVE_ARCH_HUGE_VMAP for all vmalloc in X86_64.
>> Let bpf_prog_pack to call __vmalloc_node_range() with VM_TRY_HUGE_VMAP
>> directly.
>
> Again, this changelog lacks any form of reasoning and justification.
>
> Aside of that there is absolutely nothing x86_64 specific in the patch.
>
> You might know all the details behind this change today, but will you be
> able to make sense of the above half a year from now?
>
> Even if you can, then anyone else is left in the dark.
>
> Thanks,
>
> tglx
I will provide more information in the next version.
Thanks,
Song
Powered by blists - more mailing lists