From: David Hildenbrand <david@redhat.com> To: James Morse <james.morse@arm.com> Cc: kexec@lists.infradead.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Eric Biederman <ebiederm@xmission.com>, Andrew Morton <akpm@linux-foundation.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Anshuman Khandual <anshuman.khandual@arm.com>, Bhupesh Sharma <bhsharma@redhat.com> Subject: Re: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use Date: Mon, 30 Mar 2020 15:18:13 +0200 [thread overview] Message-ID: <fd6434ca-0af2-ef75-a83a-2ef3d2deefda@redhat.com> (raw) In-Reply-To: <0ee0556d-9903-1b17-8c58-e847f4c00816@arm.com> On 27.03.20 16:42, James Morse wrote: > Hi David, > > On 3/27/20 9:27 AM, David Hildenbrand wrote: >> On 26.03.20 19:07, James Morse wrote: >>> arm64 recently queued support for memory hotremove, which led to some >>> new corner cases for kexec. >>> >>> If the kexec segments are loaded for a removable region, that region may >>> be removed before kexec actually occurs. This causes the first kernel to >>> lockup when applying the relocations. (I've triggered this on x86 too). >>> >>> The first patch adds a memory notifier for kexec so that it can refuse >>> to allow in-use regions to be taken offline. > >> IIRC other architectures handle that by setting the affected pages >> PageReserved. Any reason why to not stick to the same? > > Hmm, I didn't spot this. How come core code doesn't do it if its needed? > > Doesn't PG_Reserved prevent the page from being used for regular allocations? > (or is that only if its done early) > > I prefer the runtime check as the dmesg output gives the user some chance of > knowing why their memory-offline failed, and doing something about it! I was confused which memory we are trying to protect. Understood now, that you are dealing with the target physical memory described during described during kexec_load. [...] > >> Also, makedumpfile will check if the >> sections are still around IIRC. > > Curious. I thought the vmcore was virtually addressed, how does it know which > linear-map portions correspond to sysfs memory nodes with KASLR? That's a very interesting question. I remember there was KASLR support being implemented specifically for that - but I don't know any details. >> Not sure what you mean by "Unaware kdump from user-space". > > The existing kexec-tools binaries, that (I assume) don't go probing to find out > if 'System RAM' is removable or not, loading a kdump kernel, along with the > user-space generated blob that describes the first kernel's memory usage to the > second kernel. Finally understood how kexec without kdump works, thanks. -- Thanks, David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com> To: James Morse <james.morse@arm.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, Bhupesh Sharma <bhsharma@redhat.com>, kexec@lists.infradead.org, linux-mm@kvack.org, Eric Biederman <ebiederm@xmission.com>, Andrew Morton <akpm@linux-foundation.org>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use Date: Mon, 30 Mar 2020 15:18:13 +0200 [thread overview] Message-ID: <fd6434ca-0af2-ef75-a83a-2ef3d2deefda@redhat.com> (raw) In-Reply-To: <0ee0556d-9903-1b17-8c58-e847f4c00816@arm.com> On 27.03.20 16:42, James Morse wrote: > Hi David, > > On 3/27/20 9:27 AM, David Hildenbrand wrote: >> On 26.03.20 19:07, James Morse wrote: >>> arm64 recently queued support for memory hotremove, which led to some >>> new corner cases for kexec. >>> >>> If the kexec segments are loaded for a removable region, that region may >>> be removed before kexec actually occurs. This causes the first kernel to >>> lockup when applying the relocations. (I've triggered this on x86 too). >>> >>> The first patch adds a memory notifier for kexec so that it can refuse >>> to allow in-use regions to be taken offline. > >> IIRC other architectures handle that by setting the affected pages >> PageReserved. Any reason why to not stick to the same? > > Hmm, I didn't spot this. How come core code doesn't do it if its needed? > > Doesn't PG_Reserved prevent the page from being used for regular allocations? > (or is that only if its done early) > > I prefer the runtime check as the dmesg output gives the user some chance of > knowing why their memory-offline failed, and doing something about it! I was confused which memory we are trying to protect. Understood now, that you are dealing with the target physical memory described during described during kexec_load. [...] > >> Also, makedumpfile will check if the >> sections are still around IIRC. > > Curious. I thought the vmcore was virtually addressed, how does it know which > linear-map portions correspond to sysfs memory nodes with KASLR? That's a very interesting question. I remember there was KASLR support being implemented specifically for that - but I don't know any details. >> Not sure what you mean by "Unaware kdump from user-space". > > The existing kexec-tools binaries, that (I assume) don't go probing to find out > if 'System RAM' is removable or not, loading a kdump kernel, along with the > user-space generated blob that describes the first kernel's memory usage to the > second kernel. Finally understood how kexec without kdump works, thanks. -- Thanks, David / dhildenb _______________________________________________ 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-03-30 13:18 UTC|newest] Thread overview: 264+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-26 18:07 [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use James Morse 2020-03-26 18:07 ` James Morse 2020-03-26 18:07 ` [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image James Morse 2020-03-26 18:07 ` James Morse 2020-03-27 0:43 ` Anshuman Khandual 2020-03-27 0:43 ` Anshuman Khandual 2020-03-27 2:54 ` Baoquan He 2020-03-27 2:54 ` Baoquan He 2020-03-27 15:46 ` James Morse 2020-03-27 15:46 ` James Morse 2020-03-27 2:34 ` Baoquan He 2020-03-27 2:34 ` Baoquan He 2020-03-27 9:30 ` David Hildenbrand 2020-03-27 9:30 ` David Hildenbrand 2020-03-27 16:56 ` James Morse 2020-03-27 16:56 ` James Morse 2020-03-27 17:06 ` David Hildenbrand 2020-03-27 17:06 ` David Hildenbrand 2020-03-27 18:07 ` James Morse 2020-03-27 18:07 ` James Morse 2020-03-27 18:52 ` David Hildenbrand 2020-03-27 18:52 ` David Hildenbrand 2020-03-30 13:00 ` James Morse 2020-03-30 13:00 ` James Morse 2020-03-30 13:13 ` David Hildenbrand 2020-03-30 13:13 ` David Hildenbrand 2020-03-30 17:17 ` James Morse 2020-03-30 17:17 ` James Morse 2020-03-30 18:14 ` David Hildenbrand 2020-03-30 18:14 ` David Hildenbrand 2020-04-10 19:10 ` Andrew Morton 2020-04-10 19:10 ` Andrew Morton 2020-04-10 19:10 ` Andrew Morton 2020-04-11 3:44 ` Baoquan He 2020-04-11 3:44 ` Baoquan He 2020-04-11 3:44 ` Baoquan He 2020-04-11 9:30 ` Russell King - ARM Linux admin 2020-04-11 9:30 ` Russell King - ARM Linux admin 2020-04-11 9:30 ` Russell King - ARM Linux admin 2020-04-11 9:58 ` David Hildenbrand 2020-04-11 9:58 ` David Hildenbrand 2020-04-11 9:58 ` David Hildenbrand 2020-04-12 5:35 ` Baoquan He 2020-04-12 5:35 ` Baoquan He 2020-04-12 5:35 ` Baoquan He 2020-04-12 8:08 ` Russell King - ARM Linux admin 2020-04-12 8:08 ` Russell King - ARM Linux admin 2020-04-12 8:08 ` Russell King - ARM Linux admin 2020-04-12 19:52 ` Eric W. Biederman 2020-04-12 19:52 ` Eric W. Biederman 2020-04-12 19:52 ` Eric W. Biederman 2020-04-12 20:37 ` Bhupesh SHARMA 2020-04-12 20:37 ` Bhupesh SHARMA 2020-04-12 20:37 ` Bhupesh SHARMA 2020-04-13 2:37 ` Baoquan He 2020-04-13 2:37 ` Baoquan He 2020-04-13 2:37 ` Baoquan He 2020-04-13 13:15 ` Eric W. Biederman 2020-04-13 13:15 ` Eric W. Biederman 2020-04-13 13:15 ` Eric W. Biederman 2020-04-13 23:01 ` Andrew Morton 2020-04-13 23:01 ` Andrew Morton 2020-04-13 23:01 ` Andrew Morton 2020-04-14 6:13 ` Eric W. Biederman 2020-04-14 6:13 ` Eric W. Biederman 2020-04-14 6:13 ` Eric W. Biederman 2020-04-14 6:40 ` Baoquan He 2020-04-14 6:40 ` Baoquan He 2020-04-14 6:40 ` Baoquan He 2020-04-14 6:51 ` Baoquan He 2020-04-14 6:51 ` Baoquan He 2020-04-14 6:51 ` Baoquan He 2020-04-14 8:00 ` David Hildenbrand 2020-04-14 8:00 ` David Hildenbrand 2020-04-14 8:00 ` David Hildenbrand 2020-04-14 9:22 ` Baoquan He 2020-04-14 9:22 ` Baoquan He 2020-04-14 9:22 ` Baoquan He 2020-04-14 9:22 ` Baoquan He 2020-04-14 9:37 ` David Hildenbrand 2020-04-14 9:37 ` David Hildenbrand 2020-04-14 9:37 ` David Hildenbrand 2020-04-14 9:37 ` David Hildenbrand 2020-04-14 14:39 ` Baoquan He 2020-04-14 14:39 ` Baoquan He 2020-04-14 14:39 ` Baoquan He 2020-04-14 14:39 ` Baoquan He 2020-04-14 14:49 ` David Hildenbrand 2020-04-14 14:49 ` David Hildenbrand 2020-04-14 14:49 ` David Hildenbrand 2020-04-14 14:49 ` David Hildenbrand 2020-04-15 2:35 ` Baoquan He 2020-04-15 2:35 ` Baoquan He 2020-04-15 2:35 ` Baoquan He 2020-04-15 2:35 ` Baoquan He 2020-04-16 13:31 ` David Hildenbrand 2020-04-16 13:31 ` David Hildenbrand 2020-04-16 13:31 ` David Hildenbrand 2020-04-16 13:31 ` David Hildenbrand 2020-04-16 14:02 ` Baoquan He 2020-04-16 14:02 ` Baoquan He 2020-04-16 14:02 ` Baoquan He 2020-04-16 14:02 ` Baoquan He 2020-04-16 14:09 ` David Hildenbrand 2020-04-16 14:09 ` David Hildenbrand 2020-04-16 14:09 ` David Hildenbrand 2020-04-16 14:09 ` David Hildenbrand 2020-04-16 14:36 ` Baoquan He 2020-04-16 14:36 ` Baoquan He 2020-04-16 14:36 ` Baoquan He 2020-04-16 14:36 ` Baoquan He 2020-04-16 14:47 ` David Hildenbrand 2020-04-16 14:47 ` David Hildenbrand 2020-04-16 14:47 ` David Hildenbrand 2020-04-16 14:47 ` David Hildenbrand 2020-04-21 13:29 ` David Hildenbrand 2020-04-21 13:29 ` David Hildenbrand 2020-04-21 13:29 ` David Hildenbrand 2020-04-21 13:29 ` David Hildenbrand 2020-04-21 13:57 ` David Hildenbrand 2020-04-21 13:57 ` David Hildenbrand 2020-04-21 13:57 ` David Hildenbrand 2020-04-21 13:57 ` David Hildenbrand 2020-04-21 13:59 ` Eric W. Biederman 2020-04-21 13:59 ` Eric W. Biederman 2020-04-21 13:59 ` Eric W. Biederman 2020-04-21 13:59 ` Eric W. Biederman 2020-04-21 14:30 ` David Hildenbrand 2020-04-21 14:30 ` David Hildenbrand 2020-04-21 14:30 ` David Hildenbrand 2020-04-21 14:30 ` David Hildenbrand 2020-04-22 9:17 ` Baoquan He 2020-04-22 9:17 ` Baoquan He 2020-04-22 9:17 ` Baoquan He 2020-04-22 9:17 ` Baoquan He 2020-04-22 9:24 ` David Hildenbrand 2020-04-22 9:24 ` David Hildenbrand 2020-04-22 9:24 ` David Hildenbrand 2020-04-22 9:24 ` David Hildenbrand 2020-04-22 9:57 ` Baoquan He 2020-04-22 9:57 ` Baoquan He 2020-04-22 9:57 ` Baoquan He 2020-04-22 9:57 ` Baoquan He 2020-04-22 10:05 ` David Hildenbrand 2020-04-22 10:05 ` David Hildenbrand 2020-04-22 10:05 ` David Hildenbrand 2020-04-22 10:05 ` David Hildenbrand 2020-04-22 10:36 ` Baoquan He 2020-04-22 10:36 ` Baoquan He 2020-04-22 10:36 ` Baoquan He 2020-04-22 10:36 ` Baoquan He 2020-04-14 9:16 ` Dave Young 2020-04-14 9:16 ` Dave Young 2020-04-14 9:16 ` Dave Young 2020-04-14 9:38 ` Dave Young 2020-04-14 9:38 ` Dave Young 2020-04-14 9:38 ` Dave Young 2020-04-14 7:05 ` David Hildenbrand 2020-04-14 7:05 ` David Hildenbrand 2020-04-14 7:05 ` David Hildenbrand 2020-04-14 16:55 ` James Morse 2020-04-14 16:55 ` James Morse 2020-04-14 16:55 ` James Morse 2020-04-14 17:41 ` David Hildenbrand 2020-04-14 17:41 ` David Hildenbrand 2020-04-14 17:41 ` David Hildenbrand 2020-04-15 20:33 ` Eric W. Biederman 2020-04-15 20:33 ` Eric W. Biederman 2020-04-15 20:33 ` Eric W. Biederman 2020-04-22 12:28 ` James Morse 2020-04-22 12:28 ` James Morse 2020-04-22 12:28 ` James Morse 2020-04-22 15:25 ` Eric W. Biederman 2020-04-22 15:25 ` Eric W. Biederman 2020-04-22 15:25 ` Eric W. Biederman 2020-04-22 16:40 ` David Hildenbrand 2020-04-22 16:40 ` David Hildenbrand 2020-04-22 16:40 ` David Hildenbrand 2020-04-23 16:29 ` Eric W. Biederman 2020-04-23 16:29 ` Eric W. Biederman 2020-04-23 16:29 ` Eric W. Biederman 2020-04-24 7:39 ` David Hildenbrand 2020-04-24 7:39 ` David Hildenbrand 2020-04-24 7:39 ` David Hildenbrand 2020-04-24 7:41 ` David Hildenbrand 2020-04-24 7:41 ` David Hildenbrand 2020-04-24 7:41 ` David Hildenbrand 2020-05-01 16:55 ` James Morse 2020-05-01 16:55 ` James Morse 2020-05-01 16:55 ` James Morse 2020-03-26 18:07 ` [PATCH 2/3] mm/memory_hotplug: Allow arch override of non boot memory resource names James Morse 2020-03-26 18:07 ` James Morse 2020-03-27 9:59 ` David Hildenbrand 2020-03-27 9:59 ` David Hildenbrand 2020-03-27 15:39 ` James Morse 2020-03-27 15:39 ` James Morse 2020-03-30 13:23 ` David Hildenbrand 2020-03-30 13:23 ` David Hildenbrand 2020-03-30 17:17 ` James Morse 2020-03-30 17:17 ` James Morse 2020-04-02 5:49 ` Dave Young 2020-04-02 5:49 ` Dave Young 2020-04-02 5:49 ` Dave Young 2020-04-02 6:12 ` piliu 2020-04-02 6:12 ` piliu 2020-04-02 6:12 ` piliu 2020-04-14 17:21 ` James Morse 2020-04-14 17:21 ` James Morse 2020-04-14 17:21 ` James Morse 2020-04-15 20:36 ` Eric W. Biederman 2020-04-15 20:36 ` Eric W. Biederman 2020-04-15 20:36 ` Eric W. Biederman 2020-04-22 12:14 ` James Morse 2020-04-22 12:14 ` James Morse 2020-04-22 12:14 ` James Morse 2020-05-09 0:45 ` Andrew Morton 2020-05-09 0:45 ` Andrew Morton 2020-05-09 0:45 ` Andrew Morton 2020-05-11 8:35 ` David Hildenbrand 2020-05-11 8:35 ` David Hildenbrand 2020-05-11 8:35 ` David Hildenbrand 2020-03-26 18:07 ` [PATCH 3/3] arm64: memory: Give hotplug memory a different resource name James Morse 2020-03-26 18:07 ` James Morse 2020-03-30 19:01 ` David Hildenbrand 2020-03-30 19:01 ` David Hildenbrand 2020-04-15 20:37 ` Eric W. Biederman 2020-04-15 20:37 ` Eric W. Biederman 2020-04-15 20:37 ` Eric W. Biederman 2020-04-22 12:14 ` James Morse 2020-04-22 12:14 ` James Morse 2020-04-22 12:14 ` James Morse 2020-03-27 2:11 ` [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use Baoquan He 2020-03-27 2:11 ` Baoquan He 2020-03-27 15:40 ` James Morse 2020-03-27 15:40 ` James Morse 2020-03-27 9:27 ` David Hildenbrand 2020-03-27 9:27 ` David Hildenbrand 2020-03-27 15:42 ` James Morse 2020-03-27 15:42 ` James Morse 2020-03-30 13:18 ` David Hildenbrand [this message] 2020-03-30 13:18 ` David Hildenbrand 2020-03-30 13:55 ` Baoquan He 2020-03-30 13:55 ` Baoquan He 2020-03-30 17:17 ` James Morse 2020-03-30 17:17 ` James Morse 2020-03-31 3:46 ` Dave Young 2020-03-31 3:46 ` Dave Young 2020-04-14 17:31 ` James Morse 2020-04-14 17:31 ` James Morse 2020-04-14 17:31 ` James Morse 2020-03-31 3:38 ` Dave Young 2020-03-31 3:38 ` Dave Young 2020-04-15 20:29 ` Eric W. Biederman 2020-04-15 20:29 ` Eric W. Biederman 2020-04-15 20:29 ` Eric W. Biederman 2020-04-22 12:14 ` James Morse 2020-04-22 12:14 ` James Morse 2020-04-22 12:14 ` James Morse 2020-04-22 13:04 ` Eric W. Biederman 2020-04-22 13:04 ` Eric W. Biederman 2020-04-22 13:04 ` Eric W. Biederman 2020-04-22 15:40 ` James Morse 2020-04-22 15:40 ` James Morse 2020-04-22 15:40 ` James Morse
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=fd6434ca-0af2-ef75-a83a-2ef3d2deefda@redhat.com \ --to=david@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=anshuman.khandual@arm.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=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: linkBe 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.