From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Gavin Shan <gshan@redhat.com>, linux-arm-kernel@lists.infradead.org
Cc: Mark Rutland <mark.rutland@arm.com>,
Steve Capper <steve.capper@arm.com>,
catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
Mark Brown <broonie@kernel.org>, Marc Zyngier <maz@kernel.org>,
will@kernel.org
Subject: Re: [PATCH V4 3/3] arm64/mm/hotplug: Ensure early memory sections are all online
Date: Tue, 6 Oct 2020 08:41:04 +0530 [thread overview]
Message-ID: <8489f045-e94c-a3cc-3fc3-a7d92d19bca6@arm.com> (raw)
In-Reply-To: <471fed64-0f61-9c16-3943-2bb8f77ee810@redhat.com>
On 10/01/2020 06:23 AM, Gavin Shan wrote:
> Hi Anshuman,
>
> On 9/29/20 11:54 PM, Anshuman Khandual wrote:
>> This adds a validation function that scans the entire boot memory and makes
>> sure that all early memory sections are online. This check is essential for
>> the memory notifier to work properly, as it cannot prevent any boot memory
>> from offlining, if all sections are not online to begin with. The notifier
>> registration is skipped, if this validation does not go through. Although
>> the boot section scanning is selectively enabled with DEBUG_VM.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Marc Zyngier <maz@kernel.org>
>> Cc: Steve Capper <steve.capper@arm.com>
>> Cc: Mark Brown <broonie@kernel.org>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> arch/arm64/mm/mmu.c | 59 +++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 59 insertions(+)
>
> I don't understand why this is necessary. The core already ensure the
> corresponding section is online when trying to offline it. It's guranteed
> that section is online when the notifier is triggered. I'm not sure if
> there is anything I missed?
Current memory notifier blocks any boot memory hot removal attempt via
blocking its offlining step itself. So if some sections in boot memory
are not online (because of a bug or change in init sequence) by the
time memory block device can be removed, the notifier loses the ability
to prevent its removal. This validation here, ensures that entire boot
memory is in online state, otherwise call out sections that are not,
with an warning that those boot memory can be removed.
>
>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 90a30f5ebfc0..b67a657ea1ad 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -1522,6 +1522,62 @@ static struct notifier_block prevent_bootmem_remove_nb = {
>> .notifier_call = prevent_bootmem_remove_notifier,
>> };
>> +/*
>> + * This ensures that boot memory sections on the plaltform are online
Will fix.
> ^^^^^^^^^
>> + * during early boot. They could not be prevented from being offlined
>> + * if for some reason they are not brought online to begin with. This
>> + * help validate the basic assumption on which the above memory event
>> + * notifier works to prevent boot memory offlining and it's possible
>> + * removal.
>> + */
>> +static bool validate_bootmem_online(void)
>> +{
>> + struct memblock_region *mblk;
>> + struct mem_section *ms;
>> + unsigned long pfn, end_pfn, start, end;
>> + bool all_online = true;
>> +
>> + /*
>> + * Scanning across all memblock might be expensive
>> + * on some big memory systems. Hence enable this
>> + * validation only with DEBUG_VM.
>> + */
>> + if (!IS_ENABLED(CONFIG_DEBUG_VM))
>> + return all_online;
>> +
>> + for_each_memblock(memory, mblk) {
>> + pfn = PHYS_PFN(mblk->base);
>> + end_pfn = PHYS_PFN(mblk->base + mblk->size);
>> +
>
> It's not a good idea to access @mblk->{base, size}. There are two
> accessors: memblock_region_memory_{base, end}_pfn().
Sure, will replace.
>
>> + for (; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
>> + ms = __pfn_to_section(pfn);
>> +
>> + /*
>> + * All memory ranges in the system at this point
>> + * should have been marked early sections.
>> + */
>> + WARN_ON(!early_section(ms));
>> +
>> + /*
>> + * Memory notifier mechanism here to prevent boot
>> + * memory offlining depends on the fact that each
>> + * early section memory on the system is intially
>> + * online. Otherwise a given memory section which
>> + * is already offline will be overlooked and can
>> + * be removed completely. Call out such sections.
>> + */
>
> s/intially/initially
Will change.
>
>> + if (!online_section(ms)) {
>> + start = PFN_PHYS(pfn);
>> + end = start + (1UL << PA_SECTION_SHIFT);
>> + pr_err("Memory range [%lx %lx] is offline\n", start, end);
>> + pr_err("Memory range [%lx %lx] can be removed\n", start, end);
>> + all_online = false;
>
> These two error messages can be combined:
>
> pr_err("Memory range [%lx %lx] not online, can't be offlined\n",
> start, end);
Will change but it is actually s/can't be offlined/can be removed/ instead.
>
> I think you need to return @all_online immediately, without
> checking if the subsequent sections are online or not? :)
Thinking about this again. It might be better if the notifier registration
does not depend on return value from validate_bootmem_online(). Instead it
should proceed either way but after calling out all boot memory sections
that are not online. In that case notifier will atleast prevent removal of
some parts of boot memory which are online.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-06 3:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-29 13:54 [PATCH V4 0/3] arm64/mm/hotplug: Improve memory offline event notifier Anshuman Khandual
2020-09-29 13:54 ` [PATCH V4 1/3] arm64/mm/hotplug: Register boot memory hot remove notifier earlier Anshuman Khandual
2020-10-01 13:51 ` Catalin Marinas
2020-09-29 13:54 ` [PATCH V4 2/3] arm64/mm/hotplug: Enable MEM_OFFLINE event handling Anshuman Khandual
2020-09-30 23:57 ` Gavin Shan
2020-10-06 2:59 ` Anshuman Khandual
2020-10-12 3:27 ` Gavin Shan
2020-09-29 13:54 ` [PATCH V4 3/3] arm64/mm/hotplug: Ensure early memory sections are all online Anshuman Khandual
2020-10-01 0:53 ` Gavin Shan
2020-10-06 3:11 ` Anshuman Khandual [this message]
2020-10-12 4:07 ` Gavin Shan
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=8489f045-e94c-a3cc-3fc3-a7d92d19bca6@arm.com \
--to=anshuman.khandual@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=gshan@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=steve.capper@arm.com \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox