All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Mark Rutland <mark.rutland@arm.com>,
	linux-efi <linux-efi@vger.kernel.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Bhupesh Sharma <bhsharma@redhat.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/4] efi/arm: defer persistent reservations until after paging_init()
Date: Tue, 6 Nov 2018 21:06:56 +0100	[thread overview]
Message-ID: <CAKv+Gu_r38Bk_SZW-5qvtM7cmQ4-09dcFwNz29AyMceucdhadQ@mail.gmail.com> (raw)
In-Reply-To: <20181106190817.GN30658@n2100.armlinux.org.uk>

On 6 November 2018 at 20:08, Russell King - ARM Linux
<linux@armlinux.org.uk> 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@linaro.org> 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@armlinux.org.uk>
>> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>
>> 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.

Thanks,

WARNING: multiple messages have this Message-ID (diff)
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] efi/arm: defer persistent reservations until after paging_init()
Date: Tue, 6 Nov 2018 21:06:56 +0100	[thread overview]
Message-ID: <CAKv+Gu_r38Bk_SZW-5qvtM7cmQ4-09dcFwNz29AyMceucdhadQ@mail.gmail.com> (raw)
In-Reply-To: <20181106190817.GN30658@n2100.armlinux.org.uk>

On 6 November 2018 at 20:08, Russell King - ARM Linux
<linux@armlinux.org.uk> 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@linaro.org> 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@armlinux.org.uk>
>> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>
>> 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.

Thanks,

  reply	other threads:[~2018-11-06 20:06 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-06 11:37 [PATCH 0/4] arm/efi: fix memblock reallocation crash due to persistent reservations Ard Biesheuvel
2018-11-06 11:37 ` Ard Biesheuvel
2018-11-06 11:37 ` [PATCH 1/4] arm64: memblock: don't permit memblock resizing until linear mapping is up Ard Biesheuvel
2018-11-06 11:37   ` Ard Biesheuvel
2018-11-06 21:22   ` Will Deacon
2018-11-06 21:22     ` Will Deacon
2018-11-06 11:37 ` [PATCH 2/4] efi/arm: defer persistent reservations until after paging_init() Ard Biesheuvel
2018-11-06 11:37   ` Ard Biesheuvel
2018-11-06 19:02   ` Ard Biesheuvel
2018-11-06 19:02     ` Ard Biesheuvel
2018-11-06 19:08     ` Russell King - ARM Linux
2018-11-06 19:08       ` Russell King - ARM Linux
2018-11-06 20:06       ` Ard Biesheuvel [this message]
2018-11-06 20:06         ` Ard Biesheuvel
2018-11-06 23:49         ` Russell King - ARM Linux
2018-11-06 23:49           ` Russell King - ARM Linux
2018-11-07  9:51           ` Marc Zyngier
2018-11-07  9:51             ` Marc Zyngier
2018-11-07  9:58             ` Russell King - ARM Linux
2018-11-07  9:58               ` Russell King - ARM Linux
2018-11-07 10:04               ` Ard Biesheuvel
2018-11-07 10:04                 ` Ard Biesheuvel
2018-11-07 10:24                 ` Russell King - ARM Linux
2018-11-07 10:24                   ` Russell King - ARM Linux
2018-11-06 11:37 ` [PATCH 3/4] efi: permit multiple entries in persistent memreserve data structure Ard Biesheuvel
2018-11-06 11:37   ` Ard Biesheuvel
2018-11-06 11:37 ` [PATCH 4/4] efi: reduce the amount of memblock reservations for persistent allocations Ard Biesheuvel
2018-11-06 11:37   ` Ard Biesheuvel
2018-11-06 18:27 ` [PATCH 0/4] arm/efi: fix memblock reallocation crash due to persistent reservations Marc Zyngier
2018-11-06 18:27   ` Marc Zyngier
2018-11-06 19:01   ` Ard Biesheuvel
2018-11-06 19:01     ` Ard Biesheuvel
2018-11-06 19:40     ` Marc Zyngier
2018-11-06 19:40       ` Marc Zyngier
2018-11-06 21:34 ` Will Deacon
2018-11-06 21:34   ` Will Deacon
2018-11-06 21:39   ` Ard Biesheuvel
2018-11-06 21:39     ` Ard Biesheuvel
2018-11-06 21:46     ` Will Deacon
2018-11-06 21:46       ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKv+Gu_r38Bk_SZW-5qvtM7cmQ4-09dcFwNz29AyMceucdhadQ@mail.gmail.com \
    --to=ard.biesheuvel@linaro.org \
    --cc=bhsharma@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.