All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Baoquan He <bhe@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	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,
	James Morse <james.morse@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, piliu@redhat.com
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



WARNING: multiple messages have this Message-ID (diff)
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


WARNING: multiple messages have this Message-ID (diff)
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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
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


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2020-04-16 14:11 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 [this message]
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
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=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 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.