linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Baoquan He <bhe@redhat.com>
Cc: piliu@redhat.com, Anshuman Khandual <anshuman.khandual@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Bhupesh Sharma <bhsharma@redhat.com>,
	linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	linux-mm@kvack.org, James Morse <james.morse@arm.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image
Date: Thu, 16 Apr 2020 16:09:57 +0200	[thread overview]
Message-ID: <4e1546eb-4416-dc6d-d549-62d1cecccbc8@redhat.com> (raw)
In-Reply-To: <20200416140247.GA12723@MiWiFi-R3L-srv>

>>> Sounds doable to me, and not complicated.
>>>
>>>> images. It would apply to
>>>>
>>>> - arm64 and filter out all hotadded memory (IIRC, only boot memory can
>>>>   be used).
>>>
>>> Do you mean hot added memory after boot can't be recognized and added
>>> into system RAM on arm64?
>>
>> See patch #3 of this patch set, which wants to avoid placing kexec
>> binaries on hotplugged memory. But I have no idea what the current plan
>> regarding arm64 is (this thread exploded :) ).
>>
>> I would assume that we don't want to place kexec images on any
>> hotplugged (or rather: hot(un)pluggable) memory - on any architecture.
> 
> Yes, noticed that and James replied to DaveY.
> 
> Later, when I was considering to make a draft patch to do the picking of
> memory from normal zone, and add a notifier, as we discussed at above, I
> suddenly realized that kexec_file_load doesn't have this issue. It
> traverse system RAM bottom up to get an available region to put
> kernel/initrd/boot_param, etc. I can't think of a system where its
> low memory could be unavailable.

kexec_walk_memblock() has the option for "kbuf->top_down". Only
kexec_walk_resources() seems to ignore it.

So I think in case of memblocks (e.g., arm64), this still applies?

>>
>>>
>>>
>>>> - powerpc to filter out all LMBs that can be removed (assuming not all
>>>>   memory corresponds to LMBs that can be removed, otherwise we're in
>>>>   trouble ... :) )
>>>> - virtio-mem to filter out all memory it added.
>>>> - hyper-v to filter out partially backed memory blocks (esp. the last
>>>>   memory block it added and only partially backed it by memory).
>>>>
>>>> This would make it work for kexec_file_load(), however, I do wonder how
>>>> we would want to approach that from userspace kexec-tools when handling
>>>> it from kexec_load().
>>>
>>> Let's make kexec_file_load work firstly. Since this work is only first
>>> step to make kexec-ed kernel not break memory hotplug. After kexec
>>> rebooting, the KASLR may locate kernel into hotpluggable area too.
>>
>> Can you elaborate how that would work?
> 
> Well, boot memory can be hotplugged or not after boot, they are marked
> in uefi tables, the current kexec doesn't save and pass them into 2nd
> kenrel, when kexec kernel bootup, it need read them and avoid them to
> randomize kernel into.

What about e.g., memory hotplugged by ACPI? I would assume, that the
kexec kernel will not make use of that (IOW detected that) until the
ACPI driver comes up and re-detects + adds that memory.

Or how would that machinery work in case we have a DIMM hotplugged via ACPI?

-- 
Thanks,

David / dhildenb


  reply	other threads:[~2020-04-16 14:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200410121013.03b609fd572504c03a666f4a@linux-foundation.org>
     [not found] ` <20200411034414.GH2129@MiWiFi-R3L-srv>
     [not found]   ` <20200411093009.GH25745@shell.armlinux.org.uk>
     [not found]     ` <20200412053507.GA4247@MiWiFi-R3L-srv>
     [not found]       ` <20200412080836.GM25745@shell.armlinux.org.uk>
     [not found]         ` <87wo6klbw0.fsf@x220.int.ebiederm.org>
     [not found]           ` <20200413023701.GA20265@MiWiFi-R3L-srv>
     [not found]             ` <871rorjzmc.fsf@x220.int.ebiederm.org>
     [not found]               ` <20200414064031.GB4247@MiWiFi-R3L-srv>
     [not found]                 ` <86e96214-7053-340b-5c1a-ff97fb94d8e0@redhat.com>
2020-04-14  9:22                   ` [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image Baoquan He
2020-04-14  9:37                     ` David Hildenbrand
2020-04-14 14:39                       ` Baoquan He
2020-04-14 14:49                         ` David Hildenbrand
2020-04-15  2:35                           ` Baoquan He
2020-04-16 13:31                             ` David Hildenbrand
2020-04-16 14:02                               ` Baoquan He
2020-04-16 14:09                                 ` David Hildenbrand [this message]
2020-04-16 14:36                                   ` Baoquan He
2020-04-16 14:47                                     ` David Hildenbrand
2020-04-21 13:29                                       ` David Hildenbrand
2020-04-21 13:57                                         ` David Hildenbrand
2020-04-21 13:59                                         ` Eric W. Biederman
2020-04-21 14:30                                           ` David Hildenbrand
2020-04-22  9:17                                         ` Baoquan He
2020-04-22  9:24                                           ` David Hildenbrand
2020-04-22  9:57                                             ` Baoquan He
2020-04-22 10:05                                               ` David Hildenbrand
2020-04-22 10:36                                                 ` Baoquan He

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=4e1546eb-4416-dc6d-d549-62d1cecccbc8@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=bhe@redhat.com \
    --cc=bhsharma@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=ebiederm@xmission.com \
    --cc=james.morse@arm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=piliu@redhat.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;
as well as URLs for NNTP newsgroup(s).