Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Tom Lendacky
Cc: Brijesh Singh
Cc: x...@kernel.org
Cc: kexec@lists.infradead.org
Signed-off-by: David Hildenbrand
---
kernel/resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel
On 24.03.21 12:18, Oscar Salvador wrote:
On Mon, Mar 22, 2021 at 05:01:58PM +0100, David Hildenbrand wrote:
It used to be true that we can have busy system RAM only on the first level
in the resourc tree. However, this is no longer holds for driver-managed
system RAM (i.e., added via dax/kmem
On 23.03.21 12:06, Andy Shevchenko wrote:
On Mon, Mar 22, 2021 at 05:01:58PM +0100, David Hildenbrand wrote:
It used to be true that we can have busy system RAM only on the first level
in the resourc tree. However, this is no longer holds for driver-managed
system RAM (i.e., added via dax/kmem
On 23.03.21 12:08, Andy Shevchenko wrote:
On Mon, Mar 22, 2021 at 05:01:59PM +0100, David Hildenbrand wrote:
It used to be true that we can have system RAM only on the first level
in the resourc tree. However, this is no longer holds for driver-managed
system RAM (i.e., dax/kmem and virtio-mem
On 23.03.21 12:11, Andy Shevchenko wrote:
On Mon, Mar 22, 2021 at 05:02:00PM +0100, David Hildenbrand wrote:
All IORESOURCE_SYSTEM_RAM and IORESOURCE_MEM now properly consider the
whole resource tree, not just the first level. Let's drop the unused
first_lvl / siblings_only logic.
All
No need to iterate over empty entries.
Cc: Simon Horman
Signed-off-by: David Hildenbrand
---
kexec/arch/i386/crashdump-x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index a301ac8..43e830a 100644
o-mem
even in corner cases where we end up with a lot of individual memory
ranges.
David Hildenbrand (3):
crashdump/x86: dump any kind of "System RAM"
crashdump/x86: iterate only over actual crash memory ranges
crashdump/x86: increase CRASH_MAX_MEMORY_RANGES to 32k
kexec/
not expose
these ranges in the firmware-provided memmap.
Cc: Simon Horman
Signed-off-by: David Hildenbrand
---
kexec/arch/i386/crashdump-x86.c | 6 --
kexec/arch/i386/crashdump-x86.h | 3 ++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b
RAM now.
Note: We only want to dump this memory, we don't want to add this memory to
the memmap of an ordinary kexec'ed kernel ("fast system reboot").
[1] https://lkml.kernel.org/r/20210322160200.19633-1-da...@redhat.com
Cc: Dan Williams
Cc: Dave Hansen
Cc: Baoquan He
Cc: Simon Horm
On 22.03.21 17:01, David Hildenbrand wrote:
It used to be true that we can have busy system RAM only on the first level
in the resourc tree. However, this is no longer holds for driver-managed
system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on
lower levels.
We have two
ction
behave similar to walk_system_ram_res().
Cc: Andrew Morton
Cc: Greg Kroah-Hartman
Cc: Dan Williams
Cc: Daniel Vetter
Cc: Andy Shevchenko
Cc: Mauro Carvalho Chehab
Cc: Signed-off-by: David Hildenbrand
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
Cc: Dave Hansen
Cc: Keith Busch
Cc: Michal Hocko
Cc:
.
Cc: Andrew Morton
Cc: Greg Kroah-Hartman
Cc: Dan Williams
Cc: Daniel Vetter
Cc: Andy Shevchenko
Cc: Mauro Carvalho Chehab
Cc: Signed-off-by: David Hildenbrand
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
Cc: Dave Hansen
Cc: Keith Busch
Cc: Michal Hocko
Cc: Qian Cai
Cc: Oscar
Williams
Cc: Daniel Vetter
Cc: Andy Shevchenko
Cc: Mauro Carvalho Chehab
Cc: Signed-off-by: David Hildenbrand
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
Cc: Dave Hansen
Cc: Keith Busch
Cc: Michal Hocko
Cc: Qian Cai
Cc: Oscar Salvador
Cc: Eric Biederman
Cc: Thomas Gleixner
Cc: Ingo Molnar
On 15.09.20 04:20, Wei Yang wrote:
> On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote:
>> IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
>> always set to 0 by hardware. This is far from beautiful (and confusing),
>> and the bit only
Cc: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: kexec@lists.infradead.org
Signed-off-by: David Hildenbrand
---
include/linux/ioport.h | 4 +++-
kernel/kexec_file.c| 2 +-
mm/memory_hotplug.c| 4 ++--
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/linux/ioport.h b/inc
Cc: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: kexec@lists.infradead.org
Signed-off-by: David Hildenbrand
---
include/linux/ioport.h | 4 +++-
kernel/kexec_file.c| 2 +-
mm/memory_hotplug.c| 4 ++--
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/linux/ioport.h b/inc
On 09.09.20 09:16, Greg Kroah-Hartman wrote:
> On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote:
>> IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
>> always set to 0 by hardware. This is far from beautiful (and confusing),
>> and
Cc: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: kexec@lists.infradead.org
Signed-off-by: David Hildenbrand
---
include/linux/ioport.h | 4 +++-
kernel/kexec_file.c| 2 +-
mm/memory_hotplug.c| 4 ++--
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/linux/ioport.h b/inc
>> kexec_load():
>>
>> 1. kexec-tools could have placed kexec images on memory that will be
>> removed.
>>
>> 2. the memory map of the guest is stale (esp., might still contain
>> hotunplugged memory). /sys/firmware/memmap and /proc/iomem will be
>> updated, so kexec-tools can fix this up.
>
>
>>> Phrasing it that way is non-sense. What is important is memory
>>> available in the system. A memory map is just a reflection upon that,
>>> a memory map is not the definition of truth.
>>>
>>> So if this notifier reflects when memory is coming and going on the
>>> system this is a
On 11.05.20 13:27, Baoquan He wrote:
> On 05/11/20 at 10:19am, David Hildenbrand wrote:
>> On 09.05.20 17:14, Eric W. Biederman wrote:
>>>>> + * If the memory layout changes, any loaded kexec image should be evicted
>>>>> + * as it may contain a copy o
On 09.05.20 02:45, Andrew Morton wrote:
> On Thu, 26 Mar 2020 18:07:29 + James Morse wrote:
>
>> Memory added to the system by hotplug has a 'System RAM' resource created
>> for it. This is exposed to user-space via /proc/iomem.
>>
>> This poses problems for kexec on arm64. If kexec decides
On 09.05.20 17:14, Eric W. Biederman wrote:
> David Hildenbrand writes:
>
>> On 01.05.20 18:57, James Morse wrote:
>>> On x86, the kexec payload contains a copy of the current memory map.
>>> If memory is added or removed, this copy of the memory map becomes
>
> Am 09.05.2020 um 01:53 schrieb Andrew Morton :
>
> On Fri, 8 May 2020 10:42:14 +0200 David Hildenbrand
> wrote:
>
>> Assume we have kmem configured and loaded:
>> [root@localhost ~]# cat /proc/iomem
>> ...
>> 14000-33fff : Persi
HP_NO_FIRMWARE_MEMMAP to reflect what it is doing
- Rephrase subjects/descriptions
- Use the flag for dax/kmem
[1] https://lkml.kernel.org/r/20200429160803.109056-1-da...@redhat.com
[2] https://lkml.kernel.org/r/20200430102908.10107-1-da...@redhat.com
David Hildenbrand (4):
device-dax: Don't
and fixup a stale comment.
Fixes: 9f960da72b25 ("device-dax: "Hotremove" persistent memory that is used
like normal RAM")
Cc: sta...@vger.kernel.org # v5.3
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Pavel Tatashin
Cc: Andrew Morton
Signed-off-by: David Hildenbra
Pankaj Gupta
Cc: Wei Yang
Cc: Baoquan He
Cc: Dave Hansen
Cc: Eric Biederman
Cc: Pavel Tatashin
Cc: Dan Williams
Signed-off-by: David Hildenbrand
---
include/linux/ioport.h | 1 +
include/linux/memory_hotplug.h | 2 ++
mm/memory_hotplug.c| 62 +++
Hansen
Cc: Eric Biederman
Cc: Pavel Tatashin
Cc: Dan Williams
Signed-off-by: David Hildenbrand
---
kernel/kexec_file.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index faa74d5f6941..bb05fd52de85 100644
--- a/kernel/kexec_file.c
+++ b/kernel
plicating the string if necessary.
Acked-by: Pankaj Gupta
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Pankaj Gupta
Cc: Wei Yang
Cc: Baoquan He
Cc: Dave Hansen
Cc: Eric Biederman
Cc: Pavel Tatashin
Cc: Dan Williams
Signed-off-by: David Hildenbrand
---
drivers/dax/dax-private.h | 1 +
drivers/da
Typo in $SUBJECT, should be "add_memory_driver_managed" ...
--
Thanks,
David / dhildenb
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
1 -> v2:
- Don't change the resource name
- Rename the flag to MHP_NO_FIRMWARE_MEMMAP to reflect what it is doing
- Rephrase subjects/descriptions
- Use the flag for dax/kmem
[1] https://lkml.kernel.org/r/20200429160803.109056-1-da...@redhat.com
[2] https://lkml.kernel.org/r/20200430102908.10107
Hansen
Cc: Eric Biederman
Cc: Pavel Tatashin
Cc: Dan Williams
Signed-off-by: David Hildenbrand
---
kernel/kexec_file.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index faa74d5f6941..bb05fd52de85 100644
--- a/kernel/kexec_file.c
+++ b/kernel
He
Cc: Dave Hansen
Cc: Eric Biederman
Cc: Pavel Tatashin
Cc: Dan Williams
Signed-off-by: David Hildenbrand
---
drivers/dax/kmem.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index 3d0a7e702c94..5a645a24e359 100644
--- a/driv
ang
Cc: Baoquan He
Cc: Dave Hansen
Cc: Eric Biederman
Cc: Pavel Tatashin
Cc: Dan Williams
Signed-off-by: David Hildenbrand
---
include/linux/ioport.h | 1 +
include/linux/memory_hotplug.h | 2 ++
mm/memory_hotplug.c| 62 +++---
3 files changed,
On 01.05.20 18:57, James Morse wrote:
> On x86, the kexec payload contains a copy of the current memory map.
> If memory is added or removed, this copy of the memory map becomes
> stale. Getting this wrong may prevent the next kernel from booting.
> The first kernel may die if it tries to
On 24.04.20 09:39, David Hildenbrand wrote:
> On 23.04.20 18:29, Eric W. Biederman wrote:
>> David Hildenbrand writes:
>>
>>>> The confusing part was talking about memory being still in use,
>>>> that is actually scheduled for use in the future.
>&
On 23.04.20 18:29, Eric W. Biederman wrote:
> David Hildenbrand writes:
>
>>> The confusing part was talking about memory being still in use,
>>> that is actually scheduled for use in the future.
>>
>> +1
>>
>>>
>>>>> Usual
> The confusing part was talking about memory being still in use,
> that is actually scheduled for use in the future.
+1
>
>>> Usually somewhere in the loaded image
>>> is a copy of the memory map at the time the kexec kernel was loaded.
>>> That will invalidate the memory map as well.
>>
>>
On 22.04.20 11:57, Baoquan He wrote:
> On 04/22/20 at 11:24am, David Hildenbrand wrote:
>> On 22.04.20 11:17, Baoquan He wrote:
>>> On 04/21/20 at 03:29pm, David Hildenbrand wrote:
>>>>>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If
On 22.04.20 11:17, Baoquan He wrote:
> On 04/21/20 at 03:29pm, David Hildenbrand wrote:
>>>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
>>>> pass the efi, it won't get the SRAT table correctly, if I remember
>>>> correctly. Y
>> b) "kexec -s -l" seems to work fine. For now, the kernel does not seem
>> to get placed on virtio-mem memory (pure luck due to the left-to-right
>> search). Memory added by virtio-mem is not getting added to the e820
>> map. Once the virtio-mem driver comes back up in the kexec kernel, the
>>
On 21.04.20 15:29, David Hildenbrand wrote:
>>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
>>> pass the efi, it won't get the SRAT table correctly, if I remember
>>> correctly. Yeah, I remeber kvm guest can get memory hotplugged with
>&
>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
>> pass the efi, it won't get the SRAT table correctly, if I remember
>> correctly. Yeah, I remeber kvm guest can get memory hotplugged with
>> ACPI only, this won't happen on bare metal though. Need check carefully.
>>
>> kexec_walk_memblock() has the option for "kbuf->top_down". Only
>> kexec_walk_resources() seems to ignore it.
>
> Yeah, that top down searching is done in a found low mem area. Means
> firstly search an available region bottom up, then put kernel top down
> in that region. The reason is our
>>> 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
> Not sure if I get the notifier idea clearly. If you mean
>
> 1) Add a common function to pick memory in unmovable zone;
Not strictly required IMHO. But, minor detail.
> 2) Let DLPAR, balloon register with notifier;
Yeah, or virtio-mem, or any other technology that adds/removes memory
>> While there are a couple of ideas floating around here, my current
>> suggestion would be either
>>
>> 1. Indicate all hotplugged memory as "System RAM (hotplugged)" in
>> /proc/iomem and the firmware memmap (on all architectures). This will
>> require kexec changes,
>
>> but I would have
On 14.04.20 16:39, Baoquan He wrote:
> On 04/14/20 at 11:37am, David Hildenbrand wrote:
>> On 14.04.20 11:22, Baoquan He wrote:
>>> On 04/14/20 at 10:00am, David Hildenbrand wrote:
>>>> On 14.04.20 08:40, Baoquan He wrote:
>>>>> On 04/13/20 at 08:15a
On 14.04.20 11:22, Baoquan He wrote:
> On 04/14/20 at 10:00am, David Hildenbrand wrote:
>> On 14.04.20 08:40, Baoquan He wrote:
>>> On 04/13/20 at 08:15am, Eric W. Biederman wrote:
>>>> Baoquan He writes:
>>>>
>>>>> On 04/12/20 at 02:52pm
On 14.04.20 08:40, Baoquan He wrote:
> On 04/13/20 at 08:15am, Eric W. Biederman wrote:
>> Baoquan He writes:
>>
>>> On 04/12/20 at 02:52pm, Eric W. Biederman wrote:
The only benefit of kexec_file_load is that it is simple enough from a
kernel perspective that signatures can be
On 10.04.20 21:10, Andrew Morton wrote:
> It's unclear (to me) what is the status of this patchset. But it does appear
> that
> an new version can be expected?
>
I'd suggest to unqueue the patches until we have a consensus.
While there are a couple of ideas floating around here, my current
> Am 11.04.2020 um 11:40 schrieb Russell King - ARM Linux admin
> :
>
> On Sat, Apr 11, 2020 at 11:44:14AM +0800, Baoquan He wrote:
>> Because We tend to use kexec_file_load more and improve/enhance it in the
>> future, and gradually obsolete the old kexec_load interface which this
>>
On 26.03.20 19:07, James Morse wrote:
> If kexec chooses to place the kernel in a memory region that was
> added after boot, we fail to boot as the kernel is running from a
> location that is not described as memory by the UEFI memory map or
> the original DT.
>
> To prevent unaware user-space
>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>>> index 0a54ffac8c68..69b03dd7fc74 100644
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -42,6 +42,10 @@
>>> #include "internal.h"
>>> #include "shuffle.h"
>>>
>>> +#ifndef MEMORY_HOTPLUG_RES_NAME
>>> +#define
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.
>>
> Adding a sentence about the way kexec load works may help, the first paragraph
> would read:
>
> | Kexec allows user-space to specify the address that the kexec image should
> be
> | loaded to. Because this memory may be in use, an image loaded for kexec is
> not
> | stored in place, instead
>> 2. You do the kexec. The kexec kernel will only operate on a reserved
>> memory region (reserved via e.g., kernel cmdline crashkernel=128M).
>
> I think you are merging the kexec and kdump behaviours.
> (Wrong terminology? The things behind 'kexec -l Image' and 'kexec -p Image')
Oh, I see - I
On 27.03.20 17:56, James Morse wrote:
> Hi David,
>
> On 3/27/20 9:30 AM, David Hildenbrand wrote:
>> On 26.03.20 19:07, James Morse wrote:
>>> An image loaded for kexec is not stored in place, instead its segments
>>> are scattered through memory,
On 26.03.20 19:07, James Morse wrote:
> Memory added to the system by hotplug has a 'System RAM' resource created
> for it. This is exposed to user-space via /proc/iomem.
>
> This poses problems for kexec on arm64. If kexec decides to place the
> kernel in one of these newly onlined regions, the
On 26.03.20 19:07, James Morse wrote:
> An image loaded for kexec is not stored in place, instead its segments
> are scattered through memory, and are re-assembled when needed. In the
> meantime, the target memory may have been removed.
>
> Because mm is not aware that this memory is still in
On 26.03.20 19:07, James Morse wrote:
> Hello!
>
> 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
, commit e73016540293 ("[v1.6.7] Update version")
>>
>> Signed-off-by: Pingfan Liu
>> To: linux...@kvack.org
>> Cc: Andrew Morton
>> Cc: David Hildenbrand
>> Cc: Dan Williams
>> Cc: Oscar Salvador
>
Whatever section_mem_map coding info after hot-removed, it is reliable
> just to work on SECTION_MARKED_PRESENT bit. Fixing makedumpfile by this
> way.
>
> Signed-off-by: Pingfan Liu
> To: kexec@lists.infradead.org
> Cc: Kazuhito Hagio
> Cc: Baoquan He
> Cc: David Hil
On 17.01.20 10:49, Pingfan Liu wrote:
> On Fri, Jan 17, 2020 at 3:47 PM Michal Hocko wrote:
>>
>> On Thu 16-01-20 23:14:02, Dan Williams wrote:
>>> On Thu, Jan 16, 2020 at 10:23 PM Pingfan Liu wrote:
On Thu, Jan 16, 2020 at 3:50 PM Michal Hocko wrote:
>
> On Thu 16-01-20
On 16.01.20 09:24, Baoquan He wrote:
> On 01/16/20 at 09:14am, David Hildenbrand wrote:
>> On 16.01.20 09:06, David Hildenbrand wrote:
>>> On 16.01.20 04:01, Pingfan Liu wrote:
>>>> When fully deactivated, it is meaningless to keep the value of a section's
On 16.01.20 09:06, David Hildenbrand wrote:
> On 16.01.20 04:01, Pingfan Liu wrote:
>> When fully deactivated, it is meaningless to keep the value of a section's
>> mem_map. And its mem_map will be reassigned during re-added.
>>
>> Beside this, it breaks the user space
On 16.01.20 04:01, Pingfan Liu wrote:
> When fully deactivated, it is meaningless to keep the value of a section's
> mem_map. And its mem_map will be reassigned during re-added.
>
> Beside this, it breaks the user space tool "makedumpfile", which makes
> assumption that a hot-removed section
On 11.03.19 10:04, Dave Young wrote:
> Hi David,
> On 11/22/18 at 11:06am, David Hildenbrand wrote:
>> Right now, pages inflated as part of a balloon driver will be dumped
>> by dump tools like makedumpfile. While XEN is able to check in the
>> crash kernel whether a certa
sh the kernel by
>> dumping, when reading memory of a partially onlined memory segment
>> (for memory added by the Hyper-V balloon driver).
>>
>> Therefore, don't read and dump pages that are marked as being logically
>> offline.
>>
>> Signed-off-by: David Hildenbran
balloon driver).
Therefore, don't read and dump pages that are marked as being logically
offline.
Signed-off-by: David Hildenbrand
---
v1 -> v2:
- Fix PAGE_BUDDY_MAPCOUNT_VALUE vs. PAGE_OFFLINE_MAPCOUNT_VALUE
makedumpfile.c | 34 ++
makedumpfile.h | 1 +
2 fi
ael J. Wysocki"
Cc: Pavel Machek
Cc: Len Brown
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Michal Hocko
Cc: "Michael S. Tsirkin"
Acked-by: Pavel Machek
Acked-by: Rafael J. Wysocki
Signed-off-by: David Hildenbrand
---
kernel/power/snapshot.c | 9 +++--
1 file changed, 7 insert
ael S. Tsirkin"
Acked-by: Nadav Amit
Signed-off-by: David Hildenbrand
---
drivers/misc/vmw_balloon.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
index e6126a4b95d3..877611b5659b 100644
--- a/dr
Suggested-by: Michal Hocko
Acked-by: Michal Hocko
Acked-by: Pavel Machek
Acked-by: Rafael J. Wysocki
Signed-off-by: David Hildenbrand
---
kernel/power/snapshot.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.
Mark inflated and never onlined pages PG_offline, to tell the world that
the content is stale and should not be dumped.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Michal Hocko
Cc: "Michael S. Tsirkin"
Signed-off
"Michael S. Tsirkin"
Acked-by: Pankaj gupta
Signed-off-by: David Hildenbrand
---
drivers/hv/hv_balloon.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 211f3fe3a038..47719862e57f 100
Cc: Arnd Bergmann
Cc: Matthew Wilcox
Cc: Michal Hocko
Cc: "Michael S. Tsirkin"
Cc: Lianbo Jiang
Cc: Borislav Petkov
Cc: Kazuhito Hagio
Acked-by: Michael S. Tsirkin
Acked-by: Dave Young
Signed-off-by: David Hildenbrand
---
kernel/crash_core.c | 2 ++
1 file changed, 2 inser
"vmw_balloon: mark inflated pages PG_offline"
-- Use helper function + adapt comments
- "PM / Hibernate: exclude all PageOffline() pages"
-- Perform the check separate from swsusp checks.
- Added RBs/ACKs
David Hildenbrand (8):
mm: balloon: update comment about isolation/m
Cc: David Rientjes
Cc: Konstantin Khlebnikov
Cc: Kazuhito Hagio
Acked-by: Konstantin Khlebnikov
Acked-by: Michael S. Tsirkin
Acked-by: Pankaj gupta
Signed-off-by: David Hildenbrand
---
Documentation/admin-guide/mm/pagemap.rst | 9 ++---
fs/proc/page.c | 4
c: Matthew Wilcox
Cc: Michal Hocko
Cc: "Michael S. Tsirkin"
Acked-by: Michael S. Tsirkin
Signed-off-by: David Hildenbrand
---
include/linux/balloon_compaction.h | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/include/linux/balloon_com
by we can crash the kernel by
>> dumping, when reading memory of a partially onlined memory segment
>> (for memory added by the Hyper-V balloon driver).
>>
>> Therefore, don't read and dump pages that are marked as being logically
>
On 21.11.18 12:35, William Kucharski wrote:
> If you are adding PageOffline(page) to the condition list of the already
> existing if in
> saveable_highmem_page(), why explicitly add it as a separate statement in
> saveable_page()?
>
> It would seem more consistent to make the second check:
>
>
On 21.11.18 04:22, Nadav Amit wrote:
> Thanks for this patch!
>
>> On Nov 19, 2018, at 2:16 AM, David Hildenbrand wrote:
>>
>> Mark inflated and never onlined pages PG_offline, to tell the world that
>> the content is stale and should not be dumped.
>>
>>
On 21.11.18 07:04, Baoquan He wrote:
> On 11/19/18 at 11:16am, David Hildenbrand wrote:
>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>> index 933cb3e45b98..093c9f917ed0 100644
>> --- a/kernel/crash_core.c
>> +++ b/kernel/crash_core.c
>> @@ -
> Cc: Stephen Hemminger
>> Cc: Kairui Song
>> Cc: Vitaly Kuznetsov
>> Cc: Andrew Morton
>> Cc: Matthew Wilcox
>> Cc: Michal Hocko
>> Cc: "Michael S. Tsirkin"
>> Signed-off-by: David Hildenbrand
>> ---
>> drivers/hv/hv_ba
>
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 50ce1bddaf56..f91da3d0a67e 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -670,7 +670,7 @@ PAGEFLAG_FALSE(DoubleMap)
> #define PAGE_TYPE_BASE 0xf000
> /* Reserve
On 19.11.18 13:22, Juergen Gross wrote:
> On 19/11/2018 11:16, David Hildenbrand wrote:
>> Mark inflated and never onlined pages PG_offline, to tell the world that
>> the content is stale and should not be dumped.
>>
>> Cc: Boris Ostrovsky
>> Cc: Juergen Gross
PG_offline"
- "mm: convert PG_balloon to PG_offline"
-- After discussions, also rename the UAPI bit name (KPF_BALLOON -> KPF_OFFLINE)
David Hildenbrand (8):
mm: balloon: update comment about isolation/migration/compaction
mm: convert PG_balloon to PG_offline
kexec: export PG
balloon driver).
Therefore, don't read and dump pages that are marked as being logically
offline.
Signed-off-by: David Hildenbrand
---
makedumpfile.c | 34 ++
makedumpfile.h | 1 +
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/makedumpfile.c b
ked-by: Pavel Machek
Signed-off-by: David Hildenbrand
---
kernel/power/snapshot.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 87e6dd57819f..8d7b4d458842 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.
Suggested-by: Michal Hocko
Signed-off-by: David Hildenbrand
---
kernel/power/snapshot.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 640b2034edd6..87e6dd57819f 100644
--- a/kernel/power/snapshot.c
+++ b/ker
ael S. Tsirkin"
Signed-off-by: David Hildenbrand
---
drivers/misc/vmw_balloon.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
index e6126a4b95d3..8cc8bd9a4e32 100644
--- a/drivers/misc/vmw_ballo
them.
Cc: Andrew Morton
Cc: Dave Young
Cc: "Kirill A. Shutemov"
Cc: Baoquan He
Cc: Omar Sandoval
Cc: Arnd Bergmann
Cc: Matthew Wilcox
Cc: Michal Hocko
Cc: "Michael S. Tsirkin"
Cc: Lianbo Jiang
Cc: Borislav Petkov
Cc: Kazuhito Hagio
Signed-off-by: David Hild
Mark inflated and never onlined pages PG_offline, to tell the world that
the content is stale and should not be dumped.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Michal Hocko
Cc: "Michael S. Tsirkin"
Signed-off
c: Matthew Wilcox
Cc: Michal Hocko
Cc: "Michael S. Tsirkin"
Signed-off-by: David Hildenbrand
---
include/linux/balloon_compaction.h | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/include/linux/balloon_compaction.h
b/include/linux/balloo
"Michael S. Tsirkin"
Signed-off-by: David Hildenbrand
---
drivers/hv/hv_balloon.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 211f3fe3a038..47719862e57f 100644
--- a/drivers/hv/hv_balloo
Cc: David Rientjes
Cc: Konstantin Khlebnikov
Cc: Kazuhito Hagio
Signed-off-by: David Hildenbrand
---
Documentation/admin-guide/mm/pagemap.rst | 9 ++---
fs/proc/page.c | 4 ++--
include/linux/balloon_compaction.h | 8
include/linux/page-flags.
>> So, no, virtio-mem is not a balloon driver :)
> [...]
1. "hotplug should simply not depend on kdump at all"
In theory yes. In the current state we already have to trigger kdump to
reload whenever we add/remove a memory block.
>>>
>>> More details please.
>>
>> I just had
101 - 197 of 197 matches
Mail list logo
