[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200921143059.GO2139@willie-the-truck>
Date: Mon, 21 Sep 2020 15:31:01 +0100
From: Will Deacon <will@...nel.org>
To: Marco Elver <elver@...gle.com>
Cc: akpm@...ux-foundation.org, glider@...gle.com, hpa@...or.com,
paulmck@...nel.org, andreyknvl@...gle.com, aryabinin@...tuozzo.com,
luto@...nel.org, bp@...en8.de, catalin.marinas@....com,
cl@...ux.com, dave.hansen@...ux.intel.com, rientjes@...gle.com,
dvyukov@...gle.com, edumazet@...gle.com,
gregkh@...uxfoundation.org, hdanton@...a.com, mingo@...hat.com,
jannh@...gle.com, Jonathan.Cameron@...wei.com, corbet@....net,
iamjoonsoo.kim@....com, keescook@...omium.org,
mark.rutland@....com, penberg@...nel.org, peterz@...radead.org,
sjpark@...zon.com, tglx@...utronix.de, vbabka@...e.cz,
x86@...nel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com,
linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org
Subject: Re: [PATCH v3 03/10] arm64, kfence: enable KFENCE for ARM64
On Mon, Sep 21, 2020 at 03:26:04PM +0200, Marco Elver wrote:
> Add architecture specific implementation details for KFENCE and enable
> KFENCE for the arm64 architecture. In particular, this implements the
> required interface in <asm/kfence.h>. Currently, the arm64 version does
> not yet use a statically allocated memory pool, at the cost of a pointer
> load for each is_kfence_address().
>
> Reviewed-by: Dmitry Vyukov <dvyukov@...gle.com>
> Co-developed-by: Alexander Potapenko <glider@...gle.com>
> Signed-off-by: Alexander Potapenko <glider@...gle.com>
> Signed-off-by: Marco Elver <elver@...gle.com>
> ---
> For ARM64, we would like to solicit feedback on what the best option is
> to obtain a constant address for __kfence_pool. One option is to declare
> a memory range in the memory layout to be dedicated to KFENCE (like is
> done for KASAN), however, it is unclear if this is the best available
> option. We would like to avoid touching the memory layout.
Sorry for the delay on this.
Given that the pool is relatively small (i.e. when compared with our virtual
address space), dedicating an area of virtual space sounds like it makes
the most sense here. How early do you need it to be available?
An alternative approach would be to patch in the address at runtime, with
something like a static key to swizzle off the direct __kfence_pool load
once we're up and running.
Will
Powered by blists - more mailing lists