Re: [PATCH 2/4] efi/arm: defer persistent reservations until after paging_init()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 06, 2018 at 09:06:56PM +0100, Ard Biesheuvel wrote:
> On 6 November 2018 at 20:08, Russell King - ARM Linux
> <linux@xxxxxxxxxxxxxxx> wrote:
> > On Tue, Nov 06, 2018 at 08:02:58PM +0100, Ard Biesheuvel wrote:
> >> On 6 November 2018 at 12:37, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
> >> > The new memory EFI reservation feature we introduced to allow memory
> >> > reservations to persist across kexec may trigger an unbounded number
> >> > of calls to memblock_reserve(). The memblock subsystem can deal with
> >> > this fine, but not before memblock resizing is enabled, which we can
> >> > only do after paging_init(), when the memory we reallocate the array
> >> > into is actually mapped.
> >> >
> >> > So break out the memreserve table processing into a separate function
> >> > and call if after paging_init() on both arm64 and ARM.
> >> >
> >> > Cc: Russell King <linux@xxxxxxxxxxxxxxx>
> >> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
> >>
> >> Russell,
> >>
> >> If you are ok with this patch, may I have your ack please? I would
> >> like to send it out before the end of the week.
> >
> > You're not going to get a quick answer to this, because it needs me to
> > investigate what the effect of this change actually is by code review.
> > I can't guarantee when I'll get around to that.
> >
> 
> Fair enough.
> 
> I will drop the ARM hunk for now then, and we'll fix ARM when you have
> more time.

I don't see how you can do that - you're dropping the processing of
reserved areas out of the efi_config_parse_tables() path, so that
won't happen any more on ARM if you don't apply the ARM hunk.

So what I see at the moment is that efi_config_parse_tables() is
called prior to paging_init() - and prior to our memblock
initialisation, and you're proposing to move the processing that
marks blocks as reserved immediately after paging_init(), and
to use the normal memremap() interface to map stuff.

I'm not convinced this will work - the memory allocators have not
been setup at this point, so using memremap() will try to allocate
page tables and potentially fail.  If the normal allocators are
setup, it's way too late to be calling memblock_reserve() - the
memory will have been passed over to the page allocator according
to which memblocks are available but not reserved.

The normal page allocator is setup by mem_init(), which happens
way after setup_arch() has returned.

So, I don't see how your patch can be correct at the moment.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux