[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <768FB93A-E239-4B21-A0F1-C1206112E37E@fb.com>
Date: Wed, 17 Nov 2021 21:36:27 +0000
From: Song Liu <songliubraving@...com>
To: Peter Zijlstra <peterz@...radead.org>,
Johannes Weiner <hannes@...xchg.org>
CC: the arch/x86 maintainers <x86@...nel.org>,
bpf <bpf@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"ast@...nel.org" <ast@...nel.org>,
"daniel@...earbox.net" <daniel@...earbox.net>,
"andrii@...nel.org" <andrii@...nel.org>,
Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next 2/7] set_memory: introduce
set_memory_[ro|x]_noalias
> On Nov 16, 2021, at 12:00 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Mon, Nov 15, 2021 at 11:13:42PM -0800, Song Liu wrote:
>> These allow setting ro/x for module_alloc() mapping, while leave the
>> linear mapping rw/nx.
>
> This needs a very strong rationale for *why*. How does this not
> trivially circumvent W^X ?
In this case, we want to have multiple BPF programs sharing the 2MB page.
When the JIT engine is working on one program, we would rather existing
BPF programs on the same page stay on RO+X mapping (the module_alloc()
address). The solution in this version is to let the JIT engine write to
the page via linear address.
An alternative is to only use the module_alloc() address, and flip the
read-only bit (of the whole 2MB page) back and forth. However, this
requires some serialization among different JIT jobs.
Johannes also noticed that set_memory_[ro|x] for kernel modules and BPF
programs causes splitting the 1GB linear mapping. This leads to visible
performance degradation in the tests. CC'ing him for more details on this.
Thanks,
Song
Powered by blists - more mailing lists