On Wed, Oct 14, 2020 at 09:12:37PM +0200, Marco Elver wrote: > On Thu, 8 Oct 2020 at 12:45, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Thu, Oct 08, 2020 at 11:40:52AM +0200, Marco Elver wrote: > > > On Thu, 1 Oct 2020 at 19:58, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > > > > > If you need virt_to_page() to work, the address has to be part of the > > > > > > linear/direct map. > > > We're going with dynamically allocating the pool (for both x86 and > > > arm64), [...] > We've got most of this sorted now for v5 -- thank you! > > The only thing we're wondering now, is if there are any corner cases > with using memblock_alloc'd memory for the KFENCE pool? (We'd like to > avoid page alloc's MAX_ORDER limit.) We have a version that passes > tests on x86 and arm64, but checking just in case. :-) AFAICT otherwise the only noticeable difference might be PageSlab(), if that's clear for KFENCE allocated pages? A few helpers appear to check that to determine how something was allocated (e.g. in the scatterlist and hwpoison code), and I suspect that needs to behave the same. Otherwise, I *think* using memblock_alloc should be fine on arm64; I'm not entirely sure for x86 (but suspect it's similar). On arm64: * All memory is given a struct page via memblocks_present() adding all memory memblocks. This includes memory allocated by memblock_alloc(). * All memory is mapped into the linear map via arm64's map_mem() adding all (non-nomap) memory memblocks. This includes memory allocated by memblock_alloc(). Thanks, Mark.
