All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: David Hildenbrand <david@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: Wed, 15 Apr 2020 10:35:24 +0800	[thread overview]
Message-ID: <20200415023524.GG4247@MiWiFi-R3L-srv> (raw)
In-Reply-To: <0085f460-b0c7-b25f-36a7-fa3bafaab6fe@redhat.com>

On 04/14/20 at 04:49pm, David Hildenbrand wrote:
> >>>>> The root cause is kexec-ed kernel is targeted at hotpluggable memory
> >>>>> region. Just avoiding the movable area can fix it. In kexec_file_load(),
> >>>>> just checking or picking those unmovable region to put kernel/initrd in
> >>>>> function locate_mem_hole_callback() can fix it. The page or pageblock's
> >>>>> zone is movable or not, it's easy to know. This fix doesn't need to
> >>>>> bother other component.
> >>>>
> >>>> I don't fully agree. E.g., just because memory is onlined to ZONE_NORMAL
> >>>> does not imply that it cannot get offlined and removed e.g., this is
> >>>> heavily used on ppc64, with 16MB sections.
> >>>
> >>> Really? I just know there are two kinds of mem hoplug in ppc, but don't
> >>> know the details. So in this case, is there any flag or a way to know
> >>> those memory block are hotpluggable? I am curious how those kernel data
> >>> is avoided to be put in this area. Or ppc just freely uses it for kernel
> >>> data or user space data, then try to migrate when hot remove?
> >>
> >> See
> >> arch/powerpc/platforms/pseries/hotplug-memory.c:dlpar_memory_remove_by_count()
> >>
> >> Under DLAPR, it can remove memory in LMB granularity, which is usually
> >> 16MB (== single section on ppc64). DLPAR will directly online all
> >> hotplugged memory (LMBs) from the kernel using device_online(), which
> >> will go to ZONE_NORMAL.
> >>
> >> When trying to remove memory, it simply scans for offlineable 16MB
> >> memory blocks (==section == LMB), offlines and removes them. No need for
> >> the movable zone and all the involved issues.
> > 
> > Yes, this is a different one, thanks for pointing it out. It sounds like
> > balloon driver in virt platform, doesn't it?
> 
> With DLPAR there is a hypervisor involved (which manages the actual HW
> DIMMs), so yes.
> 
> > 
> > Avoiding to put kexec kernel into movable zone can't solve this DLPAR
> > case as you said.
> > 
> >>
> >> Now, the interesting question is, can we have LMBs added during boot
> >> (not via add_memory()), that will later be removed via remove_memory().
> >> IIRC, we had BUGs related to that, so I think yes. If a section contains
> >> no unmovable allocations (after boot), it can get removed.
> > 
> > I do want to ask this question. If we can add LMB into system RAM, then
> > reload kexec can solve it. 
> > 
> > Another better way is adding a common function to filter out the
> > movable zone when search position for kexec kernel, use a arch specific
> > funciton to filter out DLPAR memory blocks for ppc only. Over there,
> > we can simply use for_each_drmem_lmb() to do that.
> 
> I was thinking about something similar. Maybe something like a notifier
> that can be used to test if selected memory can be used for kexec

Not sure if I get the notifier idea clearly. If you mean 

1) Add a common function to pick memory in unmovable zone;
2) Let DLPAR, balloon register with notifier;
3) In the common function, ask notified part to check if the picked
   unmovable memory is available for locating kexec kernel;

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?


> - 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.


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

WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: David Hildenbrand <david@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: Wed, 15 Apr 2020 10:35:24 +0800	[thread overview]
Message-ID: <20200415023524.GG4247@MiWiFi-R3L-srv> (raw)
In-Reply-To: <0085f460-b0c7-b25f-36a7-fa3bafaab6fe@redhat.com>

On 04/14/20 at 04:49pm, David Hildenbrand wrote:
> >>>>> The root cause is kexec-ed kernel is targeted at hotpluggable memory
> >>>>> region. Just avoiding the movable area can fix it. In kexec_file_load(),
> >>>>> just checking or picking those unmovable region to put kernel/initrd in
> >>>>> function locate_mem_hole_callback() can fix it. The page or pageblock's
> >>>>> zone is movable or not, it's easy to know. This fix doesn't need to
> >>>>> bother other component.
> >>>>
> >>>> I don't fully agree. E.g., just because memory is onlined to ZONE_NORMAL
> >>>> does not imply that it cannot get offlined and removed e.g., this is
> >>>> heavily used on ppc64, with 16MB sections.
> >>>
> >>> Really? I just know there are two kinds of mem hoplug in ppc, but don't
> >>> know the details. So in this case, is there any flag or a way to know
> >>> those memory block are hotpluggable? I am curious how those kernel data
> >>> is avoided to be put in this area. Or ppc just freely uses it for kernel
> >>> data or user space data, then try to migrate when hot remove?
> >>
> >> See
> >> arch/powerpc/platforms/pseries/hotplug-memory.c:dlpar_memory_remove_by_count()
> >>
> >> Under DLAPR, it can remove memory in LMB granularity, which is usually
> >> 16MB (== single section on ppc64). DLPAR will directly online all
> >> hotplugged memory (LMBs) from the kernel using device_online(), which
> >> will go to ZONE_NORMAL.
> >>
> >> When trying to remove memory, it simply scans for offlineable 16MB
> >> memory blocks (==section == LMB), offlines and removes them. No need for
> >> the movable zone and all the involved issues.
> > 
> > Yes, this is a different one, thanks for pointing it out. It sounds like
> > balloon driver in virt platform, doesn't it?
> 
> With DLPAR there is a hypervisor involved (which manages the actual HW
> DIMMs), so yes.
> 
> > 
> > Avoiding to put kexec kernel into movable zone can't solve this DLPAR
> > case as you said.
> > 
> >>
> >> Now, the interesting question is, can we have LMBs added during boot
> >> (not via add_memory()), that will later be removed via remove_memory().
> >> IIRC, we had BUGs related to that, so I think yes. If a section contains
> >> no unmovable allocations (after boot), it can get removed.
> > 
> > I do want to ask this question. If we can add LMB into system RAM, then
> > reload kexec can solve it. 
> > 
> > Another better way is adding a common function to filter out the
> > movable zone when search position for kexec kernel, use a arch specific
> > funciton to filter out DLPAR memory blocks for ppc only. Over there,
> > we can simply use for_each_drmem_lmb() to do that.
> 
> I was thinking about something similar. Maybe something like a notifier
> that can be used to test if selected memory can be used for kexec

Not sure if I get the notifier idea clearly. If you mean 

1) Add a common function to pick memory in unmovable zone;
2) Let DLPAR, balloon register with notifier;
3) In the common function, ask notified part to check if the picked
   unmovable memory is available for locating kexec kernel;

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?


> - 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.


WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: David Hildenbrand <david@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: Wed, 15 Apr 2020 10:35:24 +0800	[thread overview]
Message-ID: <20200415023524.GG4247@MiWiFi-R3L-srv> (raw)
In-Reply-To: <0085f460-b0c7-b25f-36a7-fa3bafaab6fe@redhat.com>

On 04/14/20 at 04:49pm, David Hildenbrand wrote:
> >>>>> The root cause is kexec-ed kernel is targeted at hotpluggable memory
> >>>>> region. Just avoiding the movable area can fix it. In kexec_file_load(),
> >>>>> just checking or picking those unmovable region to put kernel/initrd in
> >>>>> function locate_mem_hole_callback() can fix it. The page or pageblock's
> >>>>> zone is movable or not, it's easy to know. This fix doesn't need to
> >>>>> bother other component.
> >>>>
> >>>> I don't fully agree. E.g., just because memory is onlined to ZONE_NORMAL
> >>>> does not imply that it cannot get offlined and removed e.g., this is
> >>>> heavily used on ppc64, with 16MB sections.
> >>>
> >>> Really? I just know there are two kinds of mem hoplug in ppc, but don't
> >>> know the details. So in this case, is there any flag or a way to know
> >>> those memory block are hotpluggable? I am curious how those kernel data
> >>> is avoided to be put in this area. Or ppc just freely uses it for kernel
> >>> data or user space data, then try to migrate when hot remove?
> >>
> >> See
> >> arch/powerpc/platforms/pseries/hotplug-memory.c:dlpar_memory_remove_by_count()
> >>
> >> Under DLAPR, it can remove memory in LMB granularity, which is usually
> >> 16MB (== single section on ppc64). DLPAR will directly online all
> >> hotplugged memory (LMBs) from the kernel using device_online(), which
> >> will go to ZONE_NORMAL.
> >>
> >> When trying to remove memory, it simply scans for offlineable 16MB
> >> memory blocks (==section == LMB), offlines and removes them. No need for
> >> the movable zone and all the involved issues.
> > 
> > Yes, this is a different one, thanks for pointing it out. It sounds like
> > balloon driver in virt platform, doesn't it?
> 
> With DLPAR there is a hypervisor involved (which manages the actual HW
> DIMMs), so yes.
> 
> > 
> > Avoiding to put kexec kernel into movable zone can't solve this DLPAR
> > case as you said.
> > 
> >>
> >> Now, the interesting question is, can we have LMBs added during boot
> >> (not via add_memory()), that will later be removed via remove_memory().
> >> IIRC, we had BUGs related to that, so I think yes. If a section contains
> >> no unmovable allocations (after boot), it can get removed.
> > 
> > I do want to ask this question. If we can add LMB into system RAM, then
> > reload kexec can solve it. 
> > 
> > Another better way is adding a common function to filter out the
> > movable zone when search position for kexec kernel, use a arch specific
> > funciton to filter out DLPAR memory blocks for ppc only. Over there,
> > we can simply use for_each_drmem_lmb() to do that.
> 
> I was thinking about something similar. Maybe something like a notifier
> that can be used to test if selected memory can be used for kexec

Not sure if I get the notifier idea clearly. If you mean 

1) Add a common function to pick memory in unmovable zone;
2) Let DLPAR, balloon register with notifier;
3) In the common function, ask notified part to check if the picked
   unmovable memory is available for locating kexec kernel;

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?


> - 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.


_______________________________________________
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: Baoquan He <bhe@redhat.com>
To: David Hildenbrand <david@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: Wed, 15 Apr 2020 10:35:24 +0800	[thread overview]
Message-ID: <20200415023524.GG4247@MiWiFi-R3L-srv> (raw)
In-Reply-To: <0085f460-b0c7-b25f-36a7-fa3bafaab6fe@redhat.com>

On 04/14/20 at 04:49pm, David Hildenbrand wrote:
> >>>>> The root cause is kexec-ed kernel is targeted at hotpluggable memory
> >>>>> region. Just avoiding the movable area can fix it. In kexec_file_load(),
> >>>>> just checking or picking those unmovable region to put kernel/initrd in
> >>>>> function locate_mem_hole_callback() can fix it. The page or pageblock's
> >>>>> zone is movable or not, it's easy to know. This fix doesn't need to
> >>>>> bother other component.
> >>>>
> >>>> I don't fully agree. E.g., just because memory is onlined to ZONE_NORMAL
> >>>> does not imply that it cannot get offlined and removed e.g., this is
> >>>> heavily used on ppc64, with 16MB sections.
> >>>
> >>> Really? I just know there are two kinds of mem hoplug in ppc, but don't
> >>> know the details. So in this case, is there any flag or a way to know
> >>> those memory block are hotpluggable? I am curious how those kernel data
> >>> is avoided to be put in this area. Or ppc just freely uses it for kernel
> >>> data or user space data, then try to migrate when hot remove?
> >>
> >> See
> >> arch/powerpc/platforms/pseries/hotplug-memory.c:dlpar_memory_remove_by_count()
> >>
> >> Under DLAPR, it can remove memory in LMB granularity, which is usually
> >> 16MB (== single section on ppc64). DLPAR will directly online all
> >> hotplugged memory (LMBs) from the kernel using device_online(), which
> >> will go to ZONE_NORMAL.
> >>
> >> When trying to remove memory, it simply scans for offlineable 16MB
> >> memory blocks (==section == LMB), offlines and removes them. No need for
> >> the movable zone and all the involved issues.
> > 
> > Yes, this is a different one, thanks for pointing it out. It sounds like
> > balloon driver in virt platform, doesn't it?
> 
> With DLPAR there is a hypervisor involved (which manages the actual HW
> DIMMs), so yes.
> 
> > 
> > Avoiding to put kexec kernel into movable zone can't solve this DLPAR
> > case as you said.
> > 
> >>
> >> Now, the interesting question is, can we have LMBs added during boot
> >> (not via add_memory()), that will later be removed via remove_memory().
> >> IIRC, we had BUGs related to that, so I think yes. If a section contains
> >> no unmovable allocations (after boot), it can get removed.
> > 
> > I do want to ask this question. If we can add LMB into system RAM, then
> > reload kexec can solve it. 
> > 
> > Another better way is adding a common function to filter out the
> > movable zone when search position for kexec kernel, use a arch specific
> > funciton to filter out DLPAR memory blocks for ppc only. Over there,
> > we can simply use for_each_drmem_lmb() to do that.
> 
> I was thinking about something similar. Maybe something like a notifier
> that can be used to test if selected memory can be used for kexec

Not sure if I get the notifier idea clearly. If you mean 

1) Add a common function to pick memory in unmovable zone;
2) Let DLPAR, balloon register with notifier;
3) In the common function, ask notified part to check if the picked
   unmovable memory is available for locating kexec kernel;

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?


> - 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.



  reply	other threads:[~2020-04-15  2:35 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 [this message]
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
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=20200415023524.GG4247@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=bhsharma@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=david@redhat.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.